Current time: 12-08-2019, 03:08 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
keepalive question
02-22-2014, 08:45 PM
Post: #1
keepalive question
Hello,

Our test results showed that keep-alive was not enabled:
http://www.webpagetest.org/result/140220...d32206a93/

However, on our nginx server, keepalive IS enabled. If you inspect the headers on WPT, it actually does say:

GET /skin/frontend/responsive/default/css/styles.css HTTP/1.1
Host: skin.myspicesage.com
Connection: keep-alive
Accept: text/css,*/*;q=0.1

I don't think it's an nginx setting as I have the same settings on a different machine and I'm getting all As:
http://www.webpagetest.org/result/140208...b0d72e756/

Can anyone help? Thanks in advance
Find all posts by this user
Quote this message in a reply
02-25-2014, 11:37 PM
Post: #2
RE: keepalive question
I also see keep-alive headers, but I did not dig to deep into them. Can you post what your keep-alive values are? Are you using apache >

Timeout ?
MaxKeepAliveRequests ?
Find all posts by this user
Quote this message in a reply
02-25-2014, 11:52 PM (This post was last modified: 02-25-2014 11:55 PM by robzilla.)
Post: #3
RE: keepalive question
You're looking at the request header while you should be looking at the response header. You're right in that the request header says "Connection: keep-alive", i.e. the browser would like to keep the connection alive, but the response header shows that the server refuses this with "Connection: close". You should probably take another look at your nginx configuration.
Find all posts by this user
Quote this message in a reply
02-26-2014, 01:41 AM (This post was last modified: 02-26-2014 01:46 AM by royster.)
Post: #4
RE: keepalive question
I'm using nginx. I'll post the settings in another reply. Thanks.

Robzilla, bastester, thanks.

Robzilla, I see your point about the response and I see the difference between the two tests. What's strange is that the _same_ nginx configuration below yielded an A and an F on the other. Both systems use varnish-nginx (same settings). Is it possible that it's on the load balancer settings? (The A does not have any load balancer, the F has).

Thank you.

nginx settings:
user nginx;
worker_processes 4;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;


events {
worker_connections 1024;
}


http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
autoindex off;
map $scheme $fastcgi_https { ## Detect when HTTPS is used
default off;
https on;
}

keepalive_timeout 10;

gzip on;
gzip_comp_level 2;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

# Load config files from the /etc/nginx/conf.d directory
# The default server is in conf.d/default.conf
# specific configuration files snipped.
Find all posts by this user
Quote this message in a reply
02-26-2014, 05:48 AM (This post was last modified: 02-26-2014 05:58 AM by robzilla.)
Post: #5
RE: keepalive question
Yes, your users talk to your load balancer listening on port 80/443, which in turn talks to nginx via a connection separate from the first. Because the load balancer manages all connections with the public, nginx's keepalive setting never enters the picture.

In fact, in a nginx+Varnish set-up, I would expect that Varnish handles keepalives. Whichever application faces the public.
Find all posts by this user
Quote this message in a reply
03-01-2014, 08:13 AM
Post: #6
RE: keepalive question
Just rounding out this thread - it was a load balancer setting that has since been resolved. Thanks for those who posted/helped.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)