last edited 2009/04/16 08:57 ( *) Since I switched from Apache.org to Lighttpd.net , as mentioned in How To Save 300MB RAM, I got to an old buddy I almost forgot: FastCGI.
use CGI;
parse_arguments();
do_request();
exit();
|
use FCGI;
while(get_request()) {
parse_arguments();
do_request();
}
exit(); # probably never reached
|
It's an internal (tcp or named socket) based sub-server process which handles the requests. Why should this be anything better than Apache with mod_php or mod_perl?
Here some numbers, Intel P4 2.4GHz with linux-2.6.27-7-generic, running lighttpd/1.4.19:
- perl-cgi: 18 requests/s or 55ms / request
- perl-fcgi (via named socket): 240 requests/s or 4.1ms / request
which makes about 13x speedup! It can be explained that the fcgi perl is already started and immediately handles the request - whereas a pure cgi has to load perl and then the cgi code as well.
In order to use fcgi with lighttpd see at ModFastCGI , be sure you don't use the lighty-enable-mod as it only works for php, enable it by hand in your lighttpd.conf:
- add "mod_fastcgi" into server.modules = ()
- add fastcgi.server definition within your server definition
I coded a fcgi test so after 100 or 1000 requests the while() loop would be exited - but it caused a few "500 internal error" at the client end: 1 error in 10,000-20,000 requests. In other words, to quit a fcgi causes internal errors within lighttpd for a busy web-site (@ 200 requests/s). Just a few errors you might say, but if you run something important I recommend you rather give /etc/init.d/lighttpd restart instead quitting the fcgi itself. Why? I do like to reset the fcgi because nobody is perfect, and perl might have or my fcgi code have memory leaks, and if you let it run for days and millions of requests the smallest memory leak will show up - that's why I personally prefer to reset a fcgi once a day.
See also FastCGI.com
|