Requests are not concurrent with SPDY and proxy_cache modules

Hi all,

I’m experiencing a strange behaviour on my SPDY tests.

I use nginx as a reverse proxy of a node.Js application.

I enabled spdy module and proxy_cache (nginx.conf file bellow) and I
actually see no difference in requests speed. Requests are well handed
by
SPDY protocol (one TCP connection and multiple streams catched with
tcpdump), but they should be concurrent and they actually are
sequentials
like without SPDY support.

Here are two screenshots of the waterfalls to see the behaviour

  1. With proxy_cache support and SPDY not enabled :
    https://lut.im/9QKXlT5T/LVFNWqxN

  2. With proxy_cache support and SPDY enabled :
    https://lut.im/DmJ2wqFp/43ZOyhTE

Here is the configuration file I use to test on my laptop :
8------------------------------------------------------------------------------------------------------------------------------------>

####### tests SPDY
keepalive_requests 1000;
keepalive_timeout 10;

client_body_timeout 10;
client_header_timeout 10;
types_hash_max_size 2048;

server_tokens off;

server_names_hash_bucket_size 128;
server_name_in_redirect off;

proxy_http_version 1.1;

fastcgi_buffers 256 4k;

gzip_static on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_vary on;
gzip_http_version 1.1;

ssl_session_timeout 5m;
ssl_session_cache shared:SSL:20m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers

‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK’;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;

upstream node_servers {
    keepalive 64;
    server node-server1;
    server node-server2;
}

# cache options
proxy_buffering           on;
proxy_cache_path /etc/nginx/cache/ levels=1:1:2 keys_zone=nodes:256m

inactive=2048m max_size=4096m;
proxy_ignore_client_abort off;
proxy_intercept_errors on;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control;

proxy_cache_methods       GET;
spdy_keepalive_timeout 10s; # inactivity timeout after which the 

SPDY
connection is closed
spdy_recv_timeout 4s; # timeout if nginx is currently
expecting
data from the client but nothing arrives
server {
listen 127.0.0.1:443 ssl spdy;
listen [::1]:443 ssl spdy;

    server_name beta.mydomain.com;

    ssl_certificate     /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;

    add_header  Alternate-Protocol "443:npn-spdy/3.1";
    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_redirect off;
        proxy_pass http://node_servers;
        proxy_cache nodes;
        proxy_cache_valid any 1h;
        proxy_cache_min_uses 10;
        add_header X-Nginx-Cached $upstream_cache_status;
    }
}


<------------------------------------------------------------------------------------------------------------------------------------8

More infos : nginx-1.8.0-4.fc22.x86_64

So my question is : can those two modules work together or am I missing
something in the conf ?

Thank you

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,259906,259906#msg-259906

On Friday 26 June 2015 10:13:04 vgallissot wrote:

Hi all,

I’m experiencing a strange behaviour on my SPDY tests.

I use nginx as a reverse proxy of a node.Js application.

I enabled spdy module and proxy_cache (nginx.conf file bellow) and I
actually see no difference in requests speed.

SPDY (and HTTP/2.0 as well) has no performance benefits for low-latency
connections.

https://lut.im/DmJ2wqFp/43ZOyhTE

[…]

You’re testing on loopback interface with about zero latency. So nginx
had time
and throughput to respond on the request before starting processing the
next one,
since most of your resources are just a few kilobytes.

wbr, Valentin V. Bartenev

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs