upstream keepalive: call for testing

[SplitIce]

Ah thanks, in which case it probably is wise to use the dynamic spawning
method with a guarunteed amount of 32 processes. (max of 2-3x that or
something along those lines) I guess.

By the way Ive tested this on HTTP backends a little without any obvious
errors, im planning on loading it on a live server later this week for some
real testing. Will this be packaged as a module in the future or do you
think it will be included in the core? I suppose Igor would be best to
answer that question.

On Sat, Jul 30, 2011 at 2:13 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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
>
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20110730/881adfb9/attachment-0001.html>