upstream keepalive: call for testing

[Maxim Dounin]

Hello!

On Sat, Jul 30, 2011 at 01:54:36AM +1000, SplitIce wrote:

> Correct me if im wrong but wouldnt the correct value to use for keepalive be
> 31(/workers) in this case?

Even 31(/workers) may be too big: (1) there may be more workers 
during reload and (2) under load you are expected to always have 
some connections busy (and hence not counted against keepalive 
limit), and requests in listen queue will be still waiting 
forever.

Maxim Dounin

> 
> On Sat, Jul 30, 2011 at 1:36 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > 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
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >
> 
> 
> 
> -- 
> Warez Scene <http://thewarezscene.org> Free Rapidshare
> Downloads<http://www.nexusddl.com>

> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel