Tuning upstream keepalive parameter

[CJ Ess]

So in this case NGINX is terminating SSL, and the upstream is HAPROXY
running the same server. HAProxy applies routing rules and distributes
requests to a pool of ~500 servers in round robin fashion. In this case
we're most interested in keeping the connections between NGINX to HAPROXY
alive. The NGINX server receives 3000 requests per second around the clock,
roughly 250 requests per worker per second. How many are active
simultaneously over the course of a second I can only guess - for the sake
of argument we could guess that if each request cook 250ms to complete,
then maybe 64 would be active simultaneously at any point.


On Thu, Nov 5, 2015 at 8:19 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Thu, Nov 05, 2015 at 12:55:36AM -0500, CJ Ess wrote:
>
> > So I'm looking for some advice on determining an appropriate number for
> the
> > keepalive parameter within an upstream stanza.
> >
> > They server processes ~3000 requests per second, and haproxy is the
> single
> > upstream destination. Dividing by the request rate by the number of
> > processors (workers) I'm thinking that maybe 256 is a good starting
> number
> > for the max keepalives.
> >
> > Is that realistic? Or should I be looking at a fraction of that number?
>
> Number of requests per second processed is mostly irrelevant.  Two
> important numbers are:
>
> - How many connections your upstream servers can handle.  It's a good
>   idea to don't exhaust all available connections with keepalive
>   ones.
>
> - How many connections are used under normal load and/or during
>   load spikes.  That is, how many simultaneous requests are
>   executed on upstream servers.  It make sense to keep comparable
>   number of connections alive to handle load fluctuations.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20151105/6dac6b37/attachment.html>