httpd w/PHP performance

[Gary Altenberg]

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.
>