upstream keepalive: call for testing
Maxim Dounin
mdounin at mdounin.ru
Fri Jul 29 15:36:40 UTC 2011
Hello!
On Fri, Jul 29, 2011 at 03:43:56PM +0200, Thomas Love wrote:
> >
> > > On 26 July 2011 13:57, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > >
> > > > Hello!
> > > >
> > > > Attached patch (against 1.0.5) introduces upstream keepalive
> > > > support for memcached, fastcgi and http. Note the patch is
> > > > experimental and may have problems (though it passes basic smoke
> > > > tests here). Testing is appreciated.
> > > >
> > > >
> > > Sounds great. Is it expected to work in this case:
> > >
> > > upstream fastcgi_backend {
> > > server unix:/tmp/php-fpm.sock
> > > keepalive 32;
Try something like
keepalive 10;
here instead. See below.
> > > }
> >
> > Yes (though I'm not sure if php is able to maintain connections
> > alive, but quick look suggests it should).
>
>
> Out of interest I have tested the above (on 1.0.5) under heavy load and I
> have run into a problem. 40 - 90 seconds after startup all requests start
> returning 502 and the log is flooded with:
>
> [error] 2120#0: *37802582 connect() to unix:/tmp/php-fpm.sock failed (11:
> Resource temporarily unavailable) while connecting to upstream, [...]
> upstream: "fastcgi://unix:/tmp/php-fpm.sock:"
>
> I am running php-fpm 0.5.14 with 32 * PHP 5.2.17 processes.
>
> How long it takes seems to depend on request rate. It looks like the php-fpm
> listen backlog is overflowing (it's at 8178, but that's normally sufficient
> when keepalive is disabled).
With "keepalive 32;" you keep busy all of your 32 php processes
even if there are no active requests, and there are no processes
left to process listen queue.
On the other hand, nginx will still try to establish new
connection if there are no idle one sitting in connections cache
during request processing. Therefore some requests will enter
php's listen queue and have no chance to leave it. Eventually
listen queue will overflow.
Please also note that "keepalive 10;" means each nginx worker will
keep up to 10 connections. If you are running multiple workers
you may need to use lower number.
Maxim Dounin
More information about the nginx-devel
mailing list