Forum: NGINX stub_status always give me 0 Reading when upgraded to 1.4.1

9f80cac7135e1748d308b04e89e8bc15?d=identicon&s=25 Tsz Ming WONG (Guest)
on 2013-07-17 04:36
(Received via mailing list)
Hi,

We have upgraded one of our nginx from 0.7.65 to 1.4.1 (keeping existing
configuration) and the stub_status module now always give me "0 Reading"

0.7.65
Active connections: 4798
server accepts handled requests
 1690444496 1690415734 1814927218
Reading: 573 Writing: 184 Waiting: 4041

1.4.1
Active connections: 4858
server accepts handled requests
 33056255 33056255 37277559
Reading: 0 Writing: 196 Waiting: 4386


They are both installed using Ubuntu package on 10.04 (1.4.1-1ppa1~lucid
, 0.7.65-1ubuntu2.3)

nginx version: nginx/0.7.65
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid
--lock-path=/var/lock/nginx.lock
--http-log-path=/var/log/nginx/access.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi --with-debug
--with-http_stub_status_module --with-http_flv_module
--with-http_ssl_module --with-http_dav_module
--with-http_gzip_static_module --with-http_realip_module --with-mail
--with-mail_ssl_module --with-ipv6
--add-module=/build/buildd/nginx-0.7.65/modules/nginx-upstream-fair

nginx version: nginx/1.4.1
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
--with-pcre-jit
--with-debug --with-http_addition_module --with-http_dav_module
--with-http_geoip_module --with-http_gzip_static_module
--with-http_image_filter_module --with-http_realip_module
--with-http_stub_status_module --with-http_ssl_module
--with-http_sub_module --with-http_xslt_module --with-ipv6 --with-mail
--with-mail_ssl_module
--add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-auth-pam
--add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-dav-ext-module
--add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-echo
--add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-upstream-fair
--add-module=/build/buildd/nginx-1.4.1/debian/modules/ngx_http_substitutions_filter_module



Any idea?




Best Regards,
tszming
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2013-07-17 12:30
(Received via mailing list)
Hello!

On Wed, Jul 17, 2013 at 10:34:48AM +0800, Tsz Ming WONG wrote:

>
> 1.4.1
> Active connections: 4858
> server accepts handled requests
>  33056255 33056255 37277559
> Reading: 0 Writing: 196 Waiting: 4386

This is an effect from the following change in 1.3.15:

    *) Change: opening and closing a connection without sending any data
in
       it is no longer logged to access_log with error code 400.

Connections in question no longer have an associated request
created, and as a result are counted in "waiting" instead of
"reading".

--
Maxim Dounin
http://nginx.org/en/donation.html
9f80cac7135e1748d308b04e89e8bc15?d=identicon&s=25 Tsz Ming WONG (Guest)
on 2013-07-17 12:50
(Received via mailing list)
Hi,


On Wed, Jul 17, 2013 at 6:29 PM, Maxim Dounin <mdounin@mdounin.ru>
wrote:

> stub_status



Thanks for the explanation.

But given that this is a busy server, sound abnormal if it always return
a
0? (according to the doc: reading - nginx reads request header)






Best Regards,
tszming
2154be8b4430488454f0a067e09863b9?d=identicon&s=25 Ruslan Ermilov (Guest)
on 2013-07-17 13:21
(Received via mailing list)
On Wed, Jul 17, 2013 at 06:48:53PM +0800, Tsz Ming WONG wrote:
>    Hi,
>    On Wed, Jul 17, 2013 at 6:29 PM, Maxim Dounin <[1]mdounin@mdounin.ru>
>    wrote:
>
>      stub_status
>
>    Thanks for the explanation.
>    But given that this is a busy server, sound abnormal if it always return a
>    0? (according to the doc: reading - nginx reads request header)

It means that your clients and nginx are fast enough, enjoy.  If you
absolutely need it to become non-zero, you can emulate a slow client
like this:

( echo 'GET / HTTP/1.0' ; sleep 42 ; echo ) | nc 127.0.0.1 80

substituting the address and port of your server.  During these 42
seconds, the status will show at least one connection in the
"reading" state.
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2013-07-17 14:32
(Received via mailing list)
Hello!

On Wed, Jul 17, 2013 at 06:48:53PM +0800, Tsz Ming WONG wrote:

> Thanks for the explanation.
>
> But given that this is a busy server, sound abnormal if it always return a
> 0? (according to the doc: reading - nginx reads request header)

Reading request headers happens almost immediately, especially if
request headers fit into a single packet.  That is, the number is
expected to be near 0 even on a busy system unless there are some
specific conditions like big cookies used.

--
Maxim Dounin
http://nginx.org/en/donation.html
9f80cac7135e1748d308b04e89e8bc15?d=identicon&s=25 Tsz Ming WONG (Guest)
on 2013-07-17 16:31
(Received via mailing list)
Thank you (and Maxim) for the detail explanation!


Best Regards,
tszming
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.