[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    RE: busybox Digest, Vol 83, Issue 24
From:       "George Pontis" <GPontis () z9 ! com>
Date:       2012-06-22 6:38:35
Message-ID: 012501cd5041$a6642650$f32c72f0$ () com
[Download RAW message or body]

> Date: Thu, 21 Jun 2012 12:01:35 +0200
> From: Laurent Bercot <ska-dietlibc@skarnet.org>
> To: George Pontis <GPontis@z9.com>
> Cc: busybox@busybox.net
> Subject: Re: httpd w/PHP performance
> Message-ID: <20120621100135.GA29143@skarnet.org>
> 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
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]