Analysis on Ruby on Rails Deployment Scheme

At the beginning of 2006, I received a legacy project assigned by the company, asking me to be responsible for a server end of a C/S-based system. In fact, the system is based on the HTTP protocol, because the client's colleagues
I don't know much about server-side programming. Although I use PHP to be familiar with C ++, I am very familiar with it, but it is too slow to implement more functions and higher performance. The project is very sudden
This is because this colleague has more things to do on the client. I have analyzed his database structure and PHPSource codeThen, I decided to rewrite his server according to the communication protocol with the client. To
Able to cope with the boss's demanding time constraints, I plan to use the Ruby on Rails I am learning. Later, the project was delivered smoothly in terms of functions.

Two years later, with the increase in the number of clients, the increase in client functions, the increase in interaction data with the server, and the increase in the boss's requirements for functions, I have made a lot of detours in this project, especially in deployment-or architecture.

The biggest problem I encountered was the number of concurrent connections. The data volume of each interaction between the server and the client is not large, but the content cannot be cached. Initially
Nginx/Apache + mongrel
But when a large number of concurrent requests are encountered, the mongrel process often dies. Client users often try again and again when they are unable to log on to the client, increasing
Load, resulting in the final failure of all mongrel processes.

Finally, through unremitting efforts, the existing three low-end servers can meet 5 million requests every day. Here, I will summarize some of my experiences and research results and share them with you.

Document address: http://docs.google.com/Doc? Id = ddcvzh74_28f9xppqfh

ArticlePosted on Google Docs. You are welcome to make comments on it. You can leave a message here if you have any comments or suggestions. The article is published in accordance with the "signature 3.0 mainland China" License Agreement for knowledge sharing. You are welcome to repost it.