On Thursday 19 February 2015 15:46:46 K Young wrote:
> In nginx Open, it looks like when a connection can't be assigned to a
> request, it is dropped and not enqueued for later processing. Is this
> correct?
I don't understand what you mean by "a connection can't be assigned to a
request".
> If so is the number of dropped connections equal to the difference
> between active and handled?
No, it's the difference between accepts and handled connections.
This shows how many connections nginx couldn't process due to limitations
(e.g. not enough memory or the worker_connections limit was reached).
wbr, Valentin V. Bartenev
>
> On Thu, Feb 19, 2015 at 10:34 AM, Valentin V. Bartenev <vbart@nginx.com>
> wrote:
>
> > On Thursday 19 February 2015 10:12:02 K Young wrote:
> > > Thanks Maxim, that's what I needed to know.
> > >
> > > How common would you say it is to use accept filters / deferred accept on
> > > nginx in production?
> > >
> > > Also to be perfectly certain: connections.idle
> > > <http://nginx.org/en/docs/http/ngx_http_status_module.html#data> in
> > Plus is
> > > the same as Waiting
> > > <http://nginx.org/en/docs/http/ngx_http_stub_status_module.html#data> in
> > > Open, right?
> >
> > Yes, right.
> >
> >
> > >
> > > Is "Active" on the status demo http://demo.nginx.com/status.html =
> > > read+write?
> >
> > No. It's "active" minus "idle" (i.e. waiting).
> >
> > "Read + write" can be bigger than the number of connections in case of
> > SPDY.
> > I prefer calling them as the requests metrics despite of the stub status
> > point of view. This sum actually is requests.current in the status module.
> >
> > http://demo.nginx.com/status/requests/current
> >
> > wbr, Valentin V. Bartenev
> >
> > _______________________________________________
> > nginx mailing list
> > nginx@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
> >
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
