1

If I open up Chrome devtools and go to the Network panel and then do a ctrl+F5 of my website, I notice a pattern each time.

The first request, to a php page, has a latency (waiting) time of 74ms. pinging my server takes 35ms, so I'm reasonably happy that the overhead of finding and serving a php page is only 40ms or so.

But then as the page goes on to load assets, most of them take ~200ms. Static jpegs/css/js etc.

Is this "normal", if so what's the reasoning for it?

If I browse directly to an image (so I'm loading just a jpeg and nothing else) then my latency for that request tends to be in the 60-70ms range.

I'm serving the site over SPDY, but disabling that doesn't seem to make any difference

This is my nginx.conf file:

pid                 /var/run/nginx.pid;
user                nginx nginx;
worker_processes    6;

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

events {
    use epoll;
    worker_connections 1024;
}


http {
server_tokens               off;

client_max_body_size        50m;

ssl_session_cache           shared:SSL:10m;
ssl_session_timeout         20m;
ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers   on;
ssl_certificate             /etc/pki/tls/certs/ssl-bundle.crt;
ssl_certificate_key         /etc/pki/tls/private/STAR_mydomain_com.key;
ssl_stapling                on;
ssl_stapling_verify         on;
ssl_dhparam                 /etc/ssl/certs/dhparam.pem;

charset                     utf-8;
source_charset              utf-8;

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

log_format                  main    '$https $remote_addr - $remote_user [$time_local] "$request" '
                                    '$status $body_bytes_sent $bytes_sent "$http_referer" '
                                    '"$http_user_agent" "$http_x_forwarded_for"';
access_log                  /var/log/nginx/access.log  main;

sendfile                    on;
keepalive_timeout           75s;
keepalive_requests          100;
open_file_cache             max=100;

etag                        off;

gzip                        on;
gzip_http_version           1.1;
gzip_comp_level             1;
gzip_static                 on;
gzip_types                  text/plain text/css application/json
                            application/x-javascript text/xml application/xml
                            application/xml+rss text/javascript image/svg+xml
                            application/vnd.ms-fontobject application/x-font-ttf
                            font/opentype;

index                       index.php index.html;


fastcgi_read_timeout        600s;


include /etc/nginx/sites-enabled/*.conf;
include /etc/nginx/conf.d/*.conf;
}

nginx version:

nginx version: nginx/1.6.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log 
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
--lock-path=/var/run/nginx.lock 
--http-client-body-temp-path=/var/cache/nginx/client_temp 
--http-proxy-temp-path=/var/cache/nginx/proxy_temp 
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx 
--group=nginx --with-http_ssl_module --with-http_realip_module 
--with-http_addition_module --with-http_sub_module --with-http_dav_module 
--with-http_flv_module --with-http_mp4_module --with-http_gunzip_module 
--with-http_gzip_static_module --with-http_random_index_module 
--with-http_secure_link_module --with-http_stub_status_module 
--with-http_auth_request_module --with-mail --with-mail_ssl_module 
--with-file-aio --with-ipv6 --with-http_spdy_module 
--with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

Devtools waterfall:

timer waterfall

AD7six
  • 2,920
  • 2
  • 21
  • 23
Codemonkey
  • 111
  • 2
  • 1
    Can you please append an image of such a load graph? And the nginx version might be useful. – Christopher Perrin Nov 08 '14 at 18:57
  • Added. I've also decided that SPDY probably *isn't* the cause. I think the false positive when I disabled it earlier must have been down to me f5ing the page rather than ctrl+f5ing it, as I couldn't reproduce it when trying to make a 2nd screenshot for you! – Codemonkey Nov 08 '14 at 19:24
  • You're loading the images from a different domain - that would explain some of the delay. the first image took about 100ms to load (seems appropriate) and you're loading enough images such that the last ones are likely to be queued by the browser check and compare (and show) the details of the timer details for a early and later image, is it waiting or queued? – AD7six Nov 09 '14 at 12:45
  • I don't know how to get Chrome to show me the difference? But as I understand it the browser should allow 6 concurrent connections to each domain. All of the images are on the same domain, it's only the html page that is on a different one. – Codemonkey Nov 09 '14 at 20:51
  • I'm pretty sure this is pure server lag. There's "sending" (when the browser sends the request), and "receiving", and the "waiting" phase happens in between those. So it can't be down to the browser domain connections limit – Codemonkey Nov 10 '14 at 00:57

0 Answers0