nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
Hello!
On Wed, Feb 18, 2015 at 09:25:01PM -0500, K Young wrote:
request
headers are read. Simultaneously, ‘request’ is incremented every time a new
request header begins to be read.
- then the connection goes into a writing state while all work is done
by nginx and by upstream components- then if the connection will be kept alive, it goes back into waiting
state, which is synonymous with ‘idle’- finally when the connection is closed, active is decremented
The things I’m least certain of about the ‘waiting’ state:
- Does active always sum up to waiting+reading+writing?
Generally yes. There are nuances with SPDY where additional
connections are emulated for SPDY streams being handled, and
waiting+reading+writing may be bigger than active.
- Does each new connection enter a waiting state just before it goes
into the reading state?
No. If there are data available right after connect (this usually
happens with accept filters / deferred accept), nginx will not
mark a newly accepted connection as waiting, and will start
reading a request directly.
- While waiting for upstream responses, is the connection in writing
state or waiting state?
Writing.
- While waiting for new client requests on an open connection, is the
connection in a waiting state?
Yes.
Is the attached sketch of the above connection states correct? (underneath
“READ” it says “request++” to indicate that this is where the request
counter gets incremented).
[image: Inline image 1]
Mostly, see above.
–
Maxim D.
http://nginx.org/
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
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?
Is “Active” on the status demo http://demo.nginx.com/status.html =
read+write?
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
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? If so is the number of dropped connections equal to the
difference
between active and handled?
On Thu, Feb 19, 2015 at 10:34 AM, Valentin V. Bartenev [email protected]