404 Not Found
http://bbs.zmke.com/dv_rss.asp?s=xm&boardid=26&id=2531&page=1&star=1&count=1
Powered By
Lite Speed Technologies is not responsible for administration and contents of this web site!
[Reprint. By commentary] Apache Nginx lighttpd HAProx Litespeed buffer analytic principle fastcgi performance
http://www.diybl.com/course/3_program/c + + / cppjs/2008828/138203.html
Busy because of the recent development of web server, for some static with the dynamic part of the interaction has been the delay have not been determined, the buffer size has also been a headache, read this article think the following is true that I still do think that simple is the best , but does not mean that all are one way to deal with, as I said in a static output socket buffer as above, I request the contents are in accordance with the size of the buffer zone to determine the distribution, even if to do so within the system will form a memory copy (socket back to deal with), but compared with the network speed and many delays, and so I think that depending on the content and decide the size of the buffer size, neither the act lighttpd, nginx, etc. are not 8K embroidery, For reception, the first allocation of a 2k-8K buffer to collect, West finished one receiving the head to know the rest of contentlength, such as the contents at between 8K-64K with 32K, 64K-infinite between K with 64K , so that process can be used in a memory copy for the network delay problem, for fastcgi support will be better, the following are the original text:
RoR deployment of the program is varied, there is Apache / Fastcgi the way, there is Nginx / Mongrel approach, have lighttpd / Fastcgi way to use someone HAProxy / Mongrel, a variety of deployment are very divergent views and not sure what kind of people way better. This article is my hope that combining our operations JavaEye website more than a year of experience (through statistical Rails of production.log, JavaEye site is currently handling more than 70 every day ten thousand 200 OK status of the Ruby dynamic request, it should be is the current load Application of the biggest RoR), for the U.S. deployment of RoR analysis of the merits of the program to help everyone select their own production environment suitable deployment of RoR.
During the discussion prior to the deployment of the program, let us look at the easy deployment of RoR web architecture:
Browser's HTTP requests to achieve the first Web server to act as a Web server is generally Lighttpd / Apache / Nginx, if the access request contains a static resource, then the Web server will be directly from the local hard disk to read a static resource files, such as picture, JavaScript, CSS and so on, back to the client browser; visit request if the request is dynamic, then the Web server URL request put forward to back-end FastCGI / Mongrel to handle, wait until the FastCGI / Mongrel handle End request will generate a page of data back to the Web servers, Web servers put the final page of data is sent to the client browser.
From RoR deployment of view, mainly by the front-end Web servers and back-end application server components: front-end Web server can use Apache, Lighttpd, Nginx and Litespeed, back-end application server can use FastCGI and Mongrel, following introduction of our categories and analysis:
First, introduce Web server
The main function of Web server has two points: First, deal with static resources, dynamic two requests are distributed to back-end application server, then receive back-end application server to generate the page data back to its browser, to serve as an information communication bridge at the focus of our analysis of this article which the latter role.
1, Apache 2.2
Apache is the world's most widely used Internet Web server, but in dealing with a static resource files are not on the performance of the most excellent Web server, but under normal circumstances, the static resources RoR web access is not the bottleneck, and therefore need not be too concerned about this point .
Apache 2.2 supports both the HTTP Proxy to connect back-end of the Mongrel application server, can also mod_fastcgi / mod_fcgid to connect FastCGI application server: When the HTTP Proxy to connect to Mongrel time, Apache receiver Mongrel back page of the largest data buffer size can only be opened to 8KB (default is 4KB or 8KB), so when the page data for more than 8KB, it may need to happen between Apache and Mongrel interact repeatedly; when mod_fastcgi connected FastCGI application server, when receiving data back Buffer size is still only 8KB only if you are using mod_fcgid, then the buffer size to 64KB, a great improvement.
2, Nginx
Nginx Russians are produced lightweight Web server, in dealing with static resources, it is said Lighttpd performance slightly higher than the 10% of resource consumption and smaller.
Mongrel using Ruby user thread mechanism to achieve concurrent multi-threaded, and used a patch fastthread improved user thread synchronization Ruby Mutex problem. But Ruby is not thread-local, we are also on the Mongrel not to IO load capacity of the network have any illusions. At the same time, Rails itself is not thread safe, therefore in the implementation of Rails code Mongrel process is completely locked status, and single process that is also not very different.
Therefore, when we use Mongrel time, usually placed at the front-end Web servers, the way through the HTTP Proxy request put forward to back-end application server Mongrel. Under such circumstances, Mongrel handle only dynamic requests, running Rails Framework to generate the page data, put the data back to the Web server on it. However, in such a deployment option, there is a very important detail has been overlooked us, Mongrel running Rails generated pages are how the data back to the Web server do? Through careful study of the source code we can find out Mongrel deal with the request the details of Rails:
1) Mongrel request received after the start of a ruby thread resolution request information
2) locking, call Rails Dispatcher to start Rails framework
3) Rails disposed to create a StringIO object, the Rails-generated pages of data written to StringIO
4) to unlock, put StringIO data flush to the Web server
The StringIO object is actually very important! It acts as an output buffer, and we imagine, when Mongrel as a stand-alone Web server, the Rails-generated pages, if relatively large, and the client browser download page is relatively slow pace, assuming there is no such a StringIO object , question what will happen? Rails thread at a time when the implementation of render method will be caught! Mutex synchronization does not unlock, Mongrel no longer be able to deal with a dynamic request.
When the Mongrel application server just as often, the StringIO is still very important, and why? We had mentioned earlier, Apache / Nginx receiving buffer only opened 8KB, if relatively large page, Mongrel will not be a one-time push to put all the data in Web servers, Web servers must wait until the receive buffer of 8K data push to the client browser after emptying the buffer zone in order to receive a 8KB data. Under the circumstances, Mongrel and Web server must be repeated between the data transmission, in order to complete the entire Web response to the process, it is clear there is no disposable put all the data page to the Web server faster. If the Web server to use Lighttpd, the situation will be different. When Mongrel put StringIO data flush when go out, Lighttpd are all disposable receiver down, do not need to interact several times, so Lighttpd + Mongrel for RoR web the actual speed is faster than Apache / Nginx + Mongel.
Mongrel using StringIO object cache output, in some exceptional circumstances will bring a lot of security problems. We assume the use of server-side program with the file permissions to download, a user is a 100MB download documents, the user uses the multi-threaded download instrument, he opened 10 concurrent download threads, then Mongrel each thread at response after read the entire document will be put into memory StringIO object which will be created so a total of 10 StringIO object to preserve the contents of 10 documents, so the memory Mongrel will look swollen to more than 1GB. And most are terrible, even when users download After The End, Mongrel memory will not come down quickly, but has maintained such a high memory footprint, this is because the GC mechanism Ruby well, not be able to timely garbage collection.
You may be less likely to feel such a big download 100MB attachment, but to JavaEye website as an example, the circle of the maximum allowable share files 10MB, as long as the users above many machines, each machine to open the circle of 100-thread download sharing documents, each Mongrel memory will be immediately occupied by more than 1GB, less than a few minutes, the server's physical memory will be depleted in response to loss of website. This defect is very easy for hackers with ulterior motives to use, web attacks. This is also why the website JavaEye not always one of the reasons Mongrel.
Through the above analysis, we know that Mongrel using Lighttpd, they can achieve the fastest execution speed RoR, but Lighttpd current 1.4.18 version of the HTTP Proxy load balancing and failover features have some bug, so very few people in general will use this approach. Most people will adopt a Mongrel with Apache2.2 or Nginx, but as we make the analysis as above, Apache / Nginx of Buffer Size is a very annoying limitation, especially in the largest open Apache can only 8KB of Buffer, I therefore propose that using Nginx with Mongrel, and Nginx put the Proxy Buffer Size settings larger, for example, is set to 64KB, to ensure that the majority of the page output results can be flush disposable go to the Web server.
2, FastCGI
A lot of people turn pale at the mention of FastCGI, as if FastCGI is a memory leak, performance failure of the culprit, or find it too FastCGI too old, and have been eliminated out of the technology, but in fact this is a very big misunderstanding. FastCGI by nature, a process of communication among the protocol, although is a relatively old protocol, but still younger than many of the HTTP protocol, HTTP protocol is not very popular just now吗?
In the PHP / ASP / JSP popular before, FastCGI once very popular, but that time the FastCGI process is prepared using C language, write up too strenuous, and PHP / ASP / JSP contrast, would be far too easy to write a , FastCGI on so gradually been thrown into a heap of history and papers inside. But the recent two years, Ruby and Python because of the rapid Web development framework of a strong rise, FastCGI seem to turn over the salted fish.
When we run FastCGI when Rails application servers, each FastCGI process are running single-threaded, taking into account the Rails is not thread safe, so Mongrel running Rails and the actual effect is the same, are in each process can only run one instance of Rails. However FastCGI at Rails to generate the page data back to the Web server and Mongrel different ways:
Mongrel Speaking in front of us opened their own output buffer, and FastCGI is completely open to any buffer zone, when the Rails implementation of render methods, FastCGI is the actual implementation of FCGI:: Stream.write method calls directly to the data addressed to the Web server. At this point if the Web server is Apache / Nginx, what will happen?
If we use mod_fastcgi module, then Apache's receive buffer is 8KB;
If we use mod_fcgid module, then Apache's receive buffer is 64KB; (mod_fcgid China are mod_fastcgi developed to replace the open-source projects are very popular in the Apache community, Who can say that China just open source "consumer" country?)
If we use Nginx server, then the default receive buffer is 8KB, but larger can be changed;
If the page data on relatively large, more than 8KB, what will happen? FastCGI process has been linked up at render Ways! Must wait until the Web server's buffer empty, put the page down after receiving all the data, FastCGI process can put an end to the Rails call, a request under the deal! So do not use Apache / Nginx with FastCGI application server, otherwise you will die of RoR application of hard to watch. According to my own test data show that the same test load, Apache with FastCGI process hang 70, but Lighttpd with FastCGI process in 30 easy finish!
When Lighttpd with FastCGI, we know Lighttpd will accept disposable FastCGI page to send back data, so FastCGI process and will not be caught. If we compare Mongrel and Lighttpd with FastCGI will find, Lighttpd with FastCGI performance of the best, Why?
Mongrel will use its own first page StringIO buffer data, and then pushed to the Lighttpd after, Lighttpd which buffer memory is also a page of data, resulting in unnecessary double buffer costs. Naturally, this will not do anything better than FastCGI buffer directly onto Lighttpd performance than high, less memory consumption.
Analysis of our program here, everyone should mind their own conclusion there is, Lighttpd + FastCGI is the best performance, the server resource consumption, the least RoR deployment program, in fact the current deployment of RoR web most frequently used is the most popular Lighttpd + FastCGI mode, and JavaEye web, natural is the deployment of this approach. Therefore, we can conduct a variety of program performance advantages and disadvantages of the queue:
Quote
Lighttpd + FastCGI> Lighttpd + Mongrel> Nginx + Mongrel> Apache + Mongrel> Ngignx + FastCGI> Apache + FastCGI
Lighttpd + FastCGI one of the performance are the best option, while the Apache + FastCGI programs are the worst performance.
Some careful Student may have a new doubt? You the final analysis, the reason why the best performance Lighttpd running RoR or Lighttpd is not limited to receiving data buffer size, and Apache / Nginx buffer size limits the所至. Why, then, to Nginx restrictions? Lighttpd If you do not limit, it would not lead to Lighttpd memory爆掉?
Nginx limiting Proxy Buffer Size is also reasonable, because Nginx for RoR is not tailored Web server, Nginx most extensive use of large or high load traffic agent server at the main Nginx applications, if no such restrictions , then Nginx side resource consumption is quite high, and there is likely to drag on the speed of agent services.
Lighttpd one of the main purposes is to provide high-performance Web servers support FastCGI, so must be tailored for FastCGI. Lighttpd client to bear the load, the more effective implementation of the accelerated pace of FastCGI. In fact, we look a little mental arithmetic, assuming Lighttpd hanging behind 1000 FastCGI process, each FastCGI process simultaneously sending data from 50KB pages, Lighttpd is all down to eat, but also consumes only 50MB of memory only, while in fact sufficient to 1000 FastCGI process support tens of millions of daily on a large website.
http://bbs.zmke.com/dv_rss.asp?s=xm&boardid=26&id=2531&page=1&star=1&count=1
Powered By
Lite Speed Technologies is not responsible for administration and contents of this web site!
[Reprint. By commentary] Apache Nginx lighttpd HAProx Litespeed buffer analytic principle fastcgi performance
http://www.diybl.com/course/3_program/c + + / cppjs/2008828/138203.html
Busy because of the recent development of web server, for some static with the dynamic part of the interaction has been the delay have not been determined, the buffer size has also been a headache, read this article think the following is true that I still do think that simple is the best , but does not mean that all are one way to deal with, as I said in a static output socket buffer as above, I request the contents are in accordance with the size of the buffer zone to determine the distribution, even if to do so within the system will form a memory copy (socket back to deal with), but compared with the network speed and many delays, and so I think that depending on the content and decide the size of the buffer size, neither the act lighttpd, nginx, etc. are not 8K embroidery, For reception, the first allocation of a 2k-8K buffer to collect, West finished one receiving the head to know the rest of contentlength, such as the contents at between 8K-64K with 32K, 64K-infinite between K with 64K , so that process can be used in a memory copy for the network delay problem, for fastcgi support will be better, the following are the original text:
RoR deployment of the program is varied, there is Apache / Fastcgi the way, there is Nginx / Mongrel approach, have lighttpd / Fastcgi way to use someone HAProxy / Mongrel, a variety of deployment are very divergent views and not sure what kind of people way better. This article is my hope that combining our operations JavaEye website more than a year of experience (through statistical Rails of production.log, JavaEye site is currently handling more than 70 every day ten thousand 200 OK status of the Ruby dynamic request, it should be is the current load Application of the biggest RoR), for the U.S. deployment of RoR analysis of the merits of the program to help everyone select their own production environment suitable deployment of RoR.
During the discussion prior to the deployment of the program, let us look at the easy deployment of RoR web architecture:
Browser's HTTP requests to achieve the first Web server to act as a Web server is generally Lighttpd / Apache / Nginx, if the access request contains a static resource, then the Web server will be directly from the local hard disk to read a static resource files, such as picture, JavaScript, CSS and so on, back to the client browser; visit request if the request is dynamic, then the Web server URL request put forward to back-end FastCGI / Mongrel to handle, wait until the FastCGI / Mongrel handle End request will generate a page of data back to the Web servers, Web servers put the final page of data is sent to the client browser.
From RoR deployment of view, mainly by the front-end Web servers and back-end application server components: front-end Web server can use Apache, Lighttpd, Nginx and Litespeed, back-end application server can use FastCGI and Mongrel, following introduction of our categories and analysis:
First, introduce Web server
The main function of Web server has two points: First, deal with static resources, dynamic two requests are distributed to back-end application server, then receive back-end application server to generate the page data back to its browser, to serve as an information communication bridge at the focus of our analysis of this article which the latter role.
1, Apache 2.2
Apache is the world's most widely used Internet Web server, but in dealing with a static resource files are not on the performance of the most excellent Web server, but under normal circumstances, the static resources RoR web access is not the bottleneck, and therefore need not be too concerned about this point .
Apache 2.2 supports both the HTTP Proxy to connect back-end of the Mongrel application server, can also mod_fastcgi / mod_fcgid to connect FastCGI application server: When the HTTP Proxy to connect to Mongrel time, Apache receiver Mongrel back page of the largest data buffer size can only be opened to 8KB (default is 4KB or 8KB), so when the page data for more than 8KB, it may need to happen between Apache and Mongrel interact repeatedly; when mod_fastcgi connected FastCGI application server, when receiving data back Buffer size is still only 8KB only if you are using mod_fcgid, then the buffer size to 64KB, a great improvement.
2, Nginx
Nginx Russians are produced lightweight Web server, in dealing with static resources, it is said Lighttpd performance slightly higher than the 10% of resource consumption and smaller.
Mongrel using Ruby user thread mechanism to achieve concurrent multi-threaded, and used a patch fastthread improved user thread synchronization Ruby Mutex problem. But Ruby is not thread-local, we are also on the Mongrel not to IO load capacity of the network have any illusions. At the same time, Rails itself is not thread safe, therefore in the implementation of Rails code Mongrel process is completely locked status, and single process that is also not very different.
Therefore, when we use Mongrel time, usually placed at the front-end Web servers, the way through the HTTP Proxy request put forward to back-end application server Mongrel. Under such circumstances, Mongrel handle only dynamic requests, running Rails Framework to generate the page data, put the data back to the Web server on it. However, in such a deployment option, there is a very important detail has been overlooked us, Mongrel running Rails generated pages are how the data back to the Web server do? Through careful study of the source code we can find out Mongrel deal with the request the details of Rails:
1) Mongrel request received after the start of a ruby thread resolution request information
2) locking, call Rails Dispatcher to start Rails framework
3) Rails disposed to create a StringIO object, the Rails-generated pages of data written to StringIO
4) to unlock, put StringIO data flush to the Web server
The StringIO object is actually very important! It acts as an output buffer, and we imagine, when Mongrel as a stand-alone Web server, the Rails-generated pages, if relatively large, and the client browser download page is relatively slow pace, assuming there is no such a StringIO object , question what will happen? Rails thread at a time when the implementation of render method will be caught! Mutex synchronization does not unlock, Mongrel no longer be able to deal with a dynamic request.
When the Mongrel application server just as often, the StringIO is still very important, and why? We had mentioned earlier, Apache / Nginx receiving buffer only opened 8KB, if relatively large page, Mongrel will not be a one-time push to put all the data in Web servers, Web servers must wait until the receive buffer of 8K data push to the client browser after emptying the buffer zone in order to receive a 8KB data. Under the circumstances, Mongrel and Web server must be repeated between the data transmission, in order to complete the entire Web response to the process, it is clear there is no disposable put all the data page to the Web server faster. If the Web server to use Lighttpd, the situation will be different. When Mongrel put StringIO data flush when go out, Lighttpd are all disposable receiver down, do not need to interact several times, so Lighttpd + Mongrel for RoR web the actual speed is faster than Apache / Nginx + Mongel.
Mongrel using StringIO object cache output, in some exceptional circumstances will bring a lot of security problems. We assume the use of server-side program with the file permissions to download, a user is a 100MB download documents, the user uses the multi-threaded download instrument, he opened 10 concurrent download threads, then Mongrel each thread at response after read the entire document will be put into memory StringIO object which will be created so a total of 10 StringIO object to preserve the contents of 10 documents, so the memory Mongrel will look swollen to more than 1GB. And most are terrible, even when users download After The End, Mongrel memory will not come down quickly, but has maintained such a high memory footprint, this is because the GC mechanism Ruby well, not be able to timely garbage collection.
You may be less likely to feel such a big download 100MB attachment, but to JavaEye website as an example, the circle of the maximum allowable share files 10MB, as long as the users above many machines, each machine to open the circle of 100-thread download sharing documents, each Mongrel memory will be immediately occupied by more than 1GB, less than a few minutes, the server's physical memory will be depleted in response to loss of website. This defect is very easy for hackers with ulterior motives to use, web attacks. This is also why the website JavaEye not always one of the reasons Mongrel.
Through the above analysis, we know that Mongrel using Lighttpd, they can achieve the fastest execution speed RoR, but Lighttpd current 1.4.18 version of the HTTP Proxy load balancing and failover features have some bug, so very few people in general will use this approach. Most people will adopt a Mongrel with Apache2.2 or Nginx, but as we make the analysis as above, Apache / Nginx of Buffer Size is a very annoying limitation, especially in the largest open Apache can only 8KB of Buffer, I therefore propose that using Nginx with Mongrel, and Nginx put the Proxy Buffer Size settings larger, for example, is set to 64KB, to ensure that the majority of the page output results can be flush disposable go to the Web server.
2, FastCGI
A lot of people turn pale at the mention of FastCGI, as if FastCGI is a memory leak, performance failure of the culprit, or find it too FastCGI too old, and have been eliminated out of the technology, but in fact this is a very big misunderstanding. FastCGI by nature, a process of communication among the protocol, although is a relatively old protocol, but still younger than many of the HTTP protocol, HTTP protocol is not very popular just now吗?
In the PHP / ASP / JSP popular before, FastCGI once very popular, but that time the FastCGI process is prepared using C language, write up too strenuous, and PHP / ASP / JSP contrast, would be far too easy to write a , FastCGI on so gradually been thrown into a heap of history and papers inside. But the recent two years, Ruby and Python because of the rapid Web development framework of a strong rise, FastCGI seem to turn over the salted fish.
When we run FastCGI when Rails application servers, each FastCGI process are running single-threaded, taking into account the Rails is not thread safe, so Mongrel running Rails and the actual effect is the same, are in each process can only run one instance of Rails. However FastCGI at Rails to generate the page data back to the Web server and Mongrel different ways:
Mongrel Speaking in front of us opened their own output buffer, and FastCGI is completely open to any buffer zone, when the Rails implementation of render methods, FastCGI is the actual implementation of FCGI:: Stream.write method calls directly to the data addressed to the Web server. At this point if the Web server is Apache / Nginx, what will happen?
If we use mod_fastcgi module, then Apache's receive buffer is 8KB;
If we use mod_fcgid module, then Apache's receive buffer is 64KB; (mod_fcgid China are mod_fastcgi developed to replace the open-source projects are very popular in the Apache community, Who can say that China just open source "consumer" country?)
If we use Nginx server, then the default receive buffer is 8KB, but larger can be changed;
If the page data on relatively large, more than 8KB, what will happen? FastCGI process has been linked up at render Ways! Must wait until the Web server's buffer empty, put the page down after receiving all the data, FastCGI process can put an end to the Rails call, a request under the deal! So do not use Apache / Nginx with FastCGI application server, otherwise you will die of RoR application of hard to watch. According to my own test data show that the same test load, Apache with FastCGI process hang 70, but Lighttpd with FastCGI process in 30 easy finish!
When Lighttpd with FastCGI, we know Lighttpd will accept disposable FastCGI page to send back data, so FastCGI process and will not be caught. If we compare Mongrel and Lighttpd with FastCGI will find, Lighttpd with FastCGI performance of the best, Why?
Mongrel will use its own first page StringIO buffer data, and then pushed to the Lighttpd after, Lighttpd which buffer memory is also a page of data, resulting in unnecessary double buffer costs. Naturally, this will not do anything better than FastCGI buffer directly onto Lighttpd performance than high, less memory consumption.
Analysis of our program here, everyone should mind their own conclusion there is, Lighttpd + FastCGI is the best performance, the server resource consumption, the least RoR deployment program, in fact the current deployment of RoR web most frequently used is the most popular Lighttpd + FastCGI mode, and JavaEye web, natural is the deployment of this approach. Therefore, we can conduct a variety of program performance advantages and disadvantages of the queue:
Quote
Lighttpd + FastCGI> Lighttpd + Mongrel> Nginx + Mongrel> Apache + Mongrel> Ngignx + FastCGI> Apache + FastCGI
Lighttpd + FastCGI one of the performance are the best option, while the Apache + FastCGI programs are the worst performance.
Some careful Student may have a new doubt? You the final analysis, the reason why the best performance Lighttpd running RoR or Lighttpd is not limited to receiving data buffer size, and Apache / Nginx buffer size limits the所至. Why, then, to Nginx restrictions? Lighttpd If you do not limit, it would not lead to Lighttpd memory爆掉?
Nginx limiting Proxy Buffer Size is also reasonable, because Nginx for RoR is not tailored Web server, Nginx most extensive use of large or high load traffic agent server at the main Nginx applications, if no such restrictions , then Nginx side resource consumption is quite high, and there is likely to drag on the speed of agent services.
Lighttpd one of the main purposes is to provide high-performance Web servers support FastCGI, so must be tailored for FastCGI. Lighttpd client to bear the load, the more effective implementation of the accelerated pace of FastCGI. In fact, we look a little mental arithmetic, assuming Lighttpd hanging behind 1000 FastCGI process, each FastCGI process simultaneously sending data from 50KB pages, Lighttpd is all down to eat, but also consumes only 50MB of memory only, while in fact sufficient to 1000 FastCGI process support tens of millions of daily on a large website.