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@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@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@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@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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

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



--
Warez Scene Free Rapidshare Downloads