Ruby on Rails website deployment-frontend and backend Selection

Ror deployment methods are divided into front-end and back-end architectures:

I. Front-end

The frontend is used to process static resources, distribute dynamic requests to the backend, and sometimes provide some additional functions, such as rewrite and redirect for specific URLs, and gzip compression for HTTP output.
Currently, you can select Apache, Lighttpd, litespeed, nginx, and haproxy as the frontend.
1. apache2.2
Apache is the most popular Web server in the world. Apache is used for more than 50% of global Internet websites. Apache2.2 + mod_proxy_balancer is a very popular and stable solution.
The only problem with apache2.2 is that Apache's performance is far behind those lightweight Web servers. On the one hand, Apache is 3-5 times slower than Lighttpd in processing static requests, and its memory consumption and CPU consumption are also an order of magnitude higher. On the other hand, mod_proxy_balancer's distribution performance is not high, which is far worse than haproxy.
2. Lighttpd
Lighttpd is a lightweight, high-performance WEB server written by Germans working in MySQL Inc. Good performance, low consumption of memory and CPU resources, supporting the vast majority of Apache functions, is an excellent replacement for Apache. Currently, Lighttpd has risen to the fourth largest Web server on the Internet in the world. Its market share is only in Apache, IIS, and sun.
The only problem with Lighttpd is that the proxy function is incomplete, so it is not suitable for use with mongrel. The proxy module of the next version of Lighttpd 1.5.0 has been rewritten, which will solve this problem.
3. litespeed
Similar to Lighttpd, commercial products are charged. For Lighttpd, there is one more web management interface, and no configuration file needs to be written. Litespeed develops an lsapi protocol for the ROR running on a single machine. It claims that it has the best performance and is better than httpd and fcgi. His proxy functions are better than Lighttpd.
The disadvantage of litespeed is that it is precisely this lsapi. Lsapi does not start a fixed number of Ruby processes when the web server is started, but dynamically creates and destroys Ruby processes based on the number of requests busy. It seems to save resources, but it is the same as apache2.2 process model, this vulnerability leaves a large number of hacker attacks. As long as hackers initiate a large number of dynamic requests, the server will be busy creating Ruby processes, resulting in CPU resource depletion and response loss.
Of course, litespeed also supports httpd and fcgi, which have the same usage as Lighttpd, so there is no such problem.
4. nginx
A lightweight and high-performance WEB server developed by a Russian, featuring good proxy performance, is recommended to replace mod_proxy_balancer of apache2.2 with mongrel cluster. Other aspects are similar to Lighttpd.
The disadvantage may be that the development time is relatively short, so far there is no official version or beta version. Not verified by enough websites.
5. haproxy
It is a pure high-performance proxy that does not process static resources. All requests are distributed to the backend.

Ii. backend
The backend is to run the ruby process and process the ROR Dynamic Request. There are two ways to run the backend Ruby process:
1. fcgi Mode
To be accurate, it cannot be called the fcgi method. In fact, it is to start a ruby process to listen to a TCP/UNIX socket and communicate with the front-end through the fcgi protocol. Therefore, fcgi does not refer to the running method of the Ruby process, but to the communication protocol used by the ruby process. This is like you can use HTTP or AJP for Tomcat communications. Tomcat runs in the same way, but the communication mode is different.
To start the ruby process in fcgi mode, you can use a spawn-fcgi tool in Lighttpd (javaeye currently uses this method ).
It is worth mentioning that the mod_fastcgi method of apache2.2 is not the same as above. The fcgi process is dynamically created and managed by Apache, this method is the same as that of the litespeed lsapi. In addition, Apache mod_fastcgi has many serious bugs and is a bad deployment method. This bad deployment method also ruined the reputation of fcgi.
FastCGI is just a protocol. Although it is old, it is not difficult to use and HTTP is also old. There is no need to deny FastCGI because of the mod_fastcgi running mode of Apache. FastCGI is just a protocol ( Program Apache mod_fastcgi module. For example, some people have poor English skills. When talking to you in English, they are always stuttering. What if you say it is a problem with the English language (FastCGI? Or is there a problem with the person you talked to (mod_fastcgi?
2. HTTP
That is to say, mongrel is used to run the ruby process. Since mongrel is actually a simple HTTP server, it can also be used as a web server separately. Mongrel is becoming increasingly popular.
I personally think the difference between fcgi and HTTP is not big. The key lies in application scenarios. Generally, the recommended combination is:
Lighttpd + fcgi or nginx + mongrel. Apache is not recommended because of performance gaps.
Why does javaeye use Lighttpd + fcgi? The reason is as follows:
1) Lighttpd has been developing for several years and has a high market share. It is a tested server and has a wide range of documents. nginx has not been tested in the market, documentation is also lacking
2) javaeye's Ruby process and web server run on one machine. Using fcgi protocol communication through UNIX socket can avoid TCP network overhead, the communication speed is faster than using TCP socket to use HTTP.

In what scenarios do haproxy be used?
Large-scale deployment. For example, if your ror application is deployed on more than a dozen servers, you can use haproxy to easily add and delete application server nodes, which improves proxy performance.