On 6/21/2012 5:01 AM, Laurent Bercot wrote:
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.
Doesn't this depend on what CPU you are using? If you are using a NO MMU
CPU doesn't a lot of alloc/free calls leave your memory very fragmented?
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.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
