> Date: Thu, 21 Jun 2012 12:01:35 +0200 > From: Laurent Bercot <[email protected]> > To: George Pontis <[email protected]> > Cc: [email protected] > Subject: Re: httpd w/PHP performance > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > I have an application that runs well using lighttpd with PHP. In an > effort > > to reduce the memory footprint I tried porting it to the busybox ( > 1.20.1 ) > > httpd. It was easy to get this working and it seems to work properly. > What > > isn't good enough is performance when executing PHP scripts. It looks > like > > the httpd is using fork/exec for each cgi, and that fork/exec can use > a lot > > of CPU. > > httpd itself, and on a fast machine with a decent OS, fork/exec > themselves, > don't use *that* much CPU. I suspect that your bottleneck might be the > startup time of the PHP interpreter, since busybox httpd is indeed > spawning > a new PHP intepreter per request. > > You could try statically linking both busybox (easy to do with the > uClibc) > and your PHP interpreter: this will cut down the costs of dynamic > linking > at process startup. For small processes (including busybox httpd), this > may > significantly speed up startup time. For larger processes, this may be > totally negligible. If you do not get noticeable performance increases > from > static linking, then the culprit is most probably the initialization > code in > the PHP interpreter. > > > > There might also be some downsides to repeated alloc/free in the > > embedded environment. > > Not at all. As long as you have enough memory to serve the requests, > and > dynamic allocations are kept to a reasonable level, there's no problem > in > performing several of them in an embedded environment. If anything, the > fork+exec approach makes memory management easier on the programmer > (and > on the kernel to some extent) since every exec and every process death > trigger automatic garbage collection for the late process. > > > > By comparison, lighttpd starts a programmable number > > of php-cgi processes at startup, then keeps them around and just > feeds > > scripts to them as needed. > > That is indeed the faster approach when the performance bottleneck is > the PHP interpreter startup time, which is likely the case here. > > > > It is feasible to go back to lighttpd but before > > giving up for this reason, I wanted to ask if my understanding or > build of > > the httpd is incorrect in some way. Any thoughts, suggestions, > comments ? > > Your understanding is correct. > As Lauri said, busybox httpd and lighttpd use different mechanisms to > run CGI programs. The fork+exec method is much simpler to implement, > and > usually efficient enough when exec'ed processes are small enough - for > instance, compiled C CGI programs. The prefork method is usually faster > with large interpreters. Depending on the results of the small test I > suggested above, you might have to switch back to lighttpd. > > -- > Laurent
Thanks to all for the explanation and thoughtful comments. It is not a surprise that the php-cgi startup constitutes a big load. For some numbers on CPU utilization, I saw about 20% with a single client sitting on a page that rolls every 500ms. That is with BB httpd, running on an Atmel at91sam9g45, with 400 MHz ARM9 core. If a second client opens the same page, the CPU utilization doubles to 40%. Under the lighttpd server, the average CPU utilization is inconsequential. I don't remember if it hit even 1% for single client. Since the scripts were very simple I falsely assumed that the BB httpd would be comparable when I decided to try it. But it would not be attractive to take a performance hit in trade for memory savings. FWIW, I am linking with uClibc. There is no perl or ruby on the system on the system so I can't duplicate Mike's time test. I tried to make an estimate using a shell script and came up with a real time around .09s per invocation of "/usr/bin/php empty.php". The root filesystem was in ram for this test. George _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
