Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

traffic stats bug (proxy_cache_valid) #8

Closed
vrody opened this issue Apr 12, 2015 · 5 comments
Closed

traffic stats bug (proxy_cache_valid) #8

vrody opened this issue Apr 12, 2015 · 5 comments
Labels

Comments

@vrody
Copy link

vrody commented Apr 12, 2015

Hi.
not counting the correct use of traffic statistics at proxy_cache_valid, the problem is shown here http://forum.nginx.org/read.php?21,257971

@vozlt
Copy link
Owner

vozlt commented Apr 14, 2015

It seems like normal situation because the proxy_cache is enabled, probably next requests would be sent from cache after processed one request.
In that case, the next requests(cached) does not pass through proxy_pass.
So probably the count of server_name in the very front will be increased.

@vrody
Copy link
Author

vrody commented Apr 14, 2015

You can check for yourself by comparing the log traffic statistics on pure Nginx and modulet and you will be surprised that no module written to the log data is correct and enabled module, you will see that the server sends a response 304 but he writes in the log is not the correct data transferred bytes
PS: Sorry for my English

@vozlt
Copy link
Owner

vozlt commented Apr 14, 2015

Please explain the situation in detail.(Your link is not an english)
The module nginx-module-vts does not touch anything related to the logging and others.
The situation may occur regardless of nginx-module-vts.(may normal situation in proxy_cache_path shared memory)
How about if you try this?

  1. disabled nginx-module-vts
  2. request(e.g. http://example.com/1.txt)
  3. request(e.g. http://example.com/1.txt)
  4. wait(proxy_cache_valid time:1m?)
  5. request(e.g. http://example.com/1.txt)
  6. nginx restart
  7. request(e.g. http://example.com/1.txt)

@vrody
Copy link
Author

vrody commented Apr 25, 2015

OK, test
dd if=/dev/zero of=/tmp/index.html bs=1M count=1

config to example.com -> proxy -> backend

log_format bbs '$status | server_name:$server_name | body_bytes_sent:$body_bytes_sent | cache_status:$upstream_cache_status';
access_log logs/access.log bbs;
proxy_cache_path one levels=1:2 keys_zone=one:10m inactive=1d max_size=1G;
vhost_traffic_status_zone;

server {
listen 80 default_server;
server_name _;
location /status {
access_log off;
vhost_traffic_status off;
vhost_traffic_status_display;
vhost_traffic_status_display_format html;
}
}

upstream backend { server 127.0.0.1:8888; }
upstream proxy { server unix:/tmp/proxy.sock; }

server {
listen 8888;
server_name backend;
location / { root /tmp; }
}

server {
listen 80;
server_name example.com;
location / {
proxy_set_header Host backend;
proxy_pass http://proxy;
proxy_cache one;
proxy_cache_revalidate on;
proxy_cache_valid 200 10s;
}
}

server {
listen unix:/tmp/proxy.sock;
server_name proxy;
location / {
proxy_pass http://$host;
}
}


make 3 request
curl example.com > /dev/null


log (bbs)
200 | server_name:backend | body_bytes_sent:1048576 | cache_status:-
200 | server_name:example.com | body_bytes_sent:1048576 | cache_status:MISS
200 | server_name:proxy | body_bytes_sent:1048576 | cache_status:-

200 | server_name:example.com | body_bytes_sent:1048576 | cache_status:HIT

304 | server_name:backend | body_bytes_sent:0 | cache_status:-
200 | server_name:example.com | body_bytes_sent:1048576 | cache_status:REVALIDATED
304 | server_name:proxy | body_bytes_sent:0 | cache_status:-


in log all good, but if we look at what we show module, we see incorrect data
2015-04-25_16-39-18

@vozlt
Copy link
Owner

vozlt commented Apr 27, 2015

The request(yours) is processed as follows:

-----------------------------------------
N   phase                           code
-----------------------------------------
1   server[example.com]             200
2   upstream[proxy]                 200
-----------------------------------------
3   server[proxy:/tmp/proxy.sock]   304
4   upstream[backend]               304
-----------------------------------------
5   server[backend]                 304
-----------------------------------------

The module(vts) is processed as follows:

In step2 is using step1's result(status_code, in_bytes, out_bytes...)
In step4 is using step3's result(status_code, in_bytes, out_bytes...)

At this moment in time, the nginx-module-vts is using the server context's result for the upstream context's result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants