Opened 5 years ago

Closed 5 years ago

#991 closed defect (invalid)

http2 uses suboptimal stream prioritization making http/2 slower than http/1.1

Reported by: vojtech.kurka@… Owned by:
Priority: major Milestone:
Component: other Version: 1.11.x
Keywords: Cc:
uname -a: Linux mycentosbox 2.6.32-573.18.1.el6.x86_64 #1 SMP Tue Feb 9 22:46:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.11.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)
built with OpenSSL 1.0.2h 3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --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-openssl=/opt/lib/openssl-1.0.2h --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-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

Description

When using connection with low bandwidth (G2, GPRS...), our page render starts 60% later with HTTP/2 with HTTP 1.1

The problem is that the main (blocking) CSS file is downloaded in parallel with images on HTTP/2. So the CSS download shares bandwidth with a lot of images that should have much lower priority. Our CSS file is 50KB gzipped and our images in total are much more than 50KB.

HTTP 1.1 doesn't download all images in parallel- it's limited by the total number of TCP connections, so the CSS download finishes much faster and page render can start much sooner.

Ilya Grigorik wrote it could be a problem in nginx http/2 implementation. https://twitter.com/igrigorik/status/737649411325468673

One image is worth thousand words, here it is: https://twitter.com/vojtechkurka/status/736212847982583809

The browser I'm using is Chrome 51 on Mac OS.

We can't use HTTP/2 to production because of this behaviour. It would make mobile user experience much worse than now on HTTP/1.1.

Attachments (5)

Screen Shot 2016-05-27 at 17.00.55.png (160.5 KB ) - added by vojtech.kurka@… 5 years ago.
chrome network debug screenshot
Screen Shot 2016-05-27 at 17.01.08.png (196.0 KB ) - added by vojtech.kurka@… 5 years ago.
chrome network debug screenshot
firefox.png (229.0 KB ) - added by Valentin V. Bartenev 5 years ago.
http2_real_2G_connection.png (106.3 KB ) - added by vojtech.kurka@… 5 years ago.
http2_network_link_conditioner_Edge.png (114.4 KB ) - added by vojtech.kurka@… 5 years ago.

Download all attachments as: .zip

Change History (12)

by vojtech.kurka@…, 5 years ago

chrome network debug screenshot

by vojtech.kurka@…, 5 years ago

chrome network debug screenshot

comment:1 by Valentin V. Bartenev, 5 years ago

Could you provide a debug log?

in reply to:  1 comment:2 by vojtech.kurka@…, 5 years ago

Replying to vbart:

Could you provide a debug log?

I'm sorry, I currently don't have nginx compiled --with-debug :(
But if you can't reproduce the described behaviour, let me know and I'll try to install nginx-debug somewhere and simulate the problem.

comment:3 by Valentin V. Bartenev, 5 years ago

I don't have that page to reproduce. Please note, that HTTP/2 prioritization in nginx usually works good with typical pages.

in reply to:  3 comment:4 by vojtech.kurka@…, 5 years ago

Replying to vbart:

I don't have that page to reproduce. Please note, that HTTP/2 prioritization in nginx usually works good with typical pages.

The page is this: http://www.glami.fr/robes-femmes/

It's served over HTTP 1.1 with HTTP/2 CDN for CSS, JS and images.

comment:5 by Valentin V. Bartenev, 5 years ago

The URL to the page doesn't really help, since your page contains a lot of resources from multiple hosts and it's not easy to save it with all the resources locally.

With Firefox it's good. See the attachment below.

Are you sure that it's not a problem with throttling tool in Chrome?

by Valentin V. Bartenev, 5 years ago

Attachment: firefox.png added

by vojtech.kurka@…, 5 years ago

by vojtech.kurka@…, 5 years ago

comment:6 by vojtech.kurka@…, 5 years ago

@vbart: You are absolutely right, the network throttling in Chrome is spoiling the results.
I tried:
1.) real 2G connection (using my phone tethering)
2.) "Network Link Conditioner" on MacOS with "Edge" setting

(see the last two screenshots attached)

In both cases, the page load was OK, CSS was correctly prioritized leading to faster render start.

My apologies for blaming nginx.

Thank you vbart for pointing me in the right direction!

Vojtech

comment:7 by Valentin V. Bartenev, 5 years ago

Resolution: invalid
Status: newclosed

Thanks for the confirmation.

Note: See TracTickets for help on using tickets.