Назад | Перейти на главную страницу

Неожиданная медленная загрузка файла после включения SPDY на Nginx

Простой статический сайт WordPress, полностью работающий по https.

Nginx conf здесь: http://pastebin.com/BrP0LThT

Единственная разница до / после:

listen       443 ssl;
listen       443 ssl spdy;

Nginx 1.8.0 с SSL, без SPDY:

Ответ из файла transitions.js:

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Sun, 28 Jun 2015 18:13:30 GMT
Content-Type: application/javascript
Last-Modified: Wed, 03 Dec 2014 14:19:08 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
ETag: W/"547f1bdc-5267"
Expires: Sun, 12 Jul 2015 18:13:30 GMT
Cache-Control: max-age=1209600
Content-Encoding: gzip

Та же настройка сервера с SPDY:

Ответ из того же файла js:

HTTP/1.1 200
cache-control: max-age=1209600
content-encoding: gzip
content-type: application/javascript
date: Sun, 28 Jun 2015 18:24:49 GMT
etag: W/"547f1bdc-5267"
expires: Sun, 12 Jul 2015 18:24:49 GMT
last-modified: Wed, 03 Dec 2014 14:19:08 GMT
server: nginx/1.8.0

Обратите внимание на то, как ответ сервера для этих файлов сильно отличается после включения SPDY.

Общее время загрузки практически такое же.

Ожидается, что он переходит от довольно диагонального водопада к прямому вертикальному перепаду, мультиплексирующемуся в полную силу.

Но все зеленые полоски TTFB на этих js, css и изображениях увеличиваются примерно до 280 мс, а синие полоски для времени загрузки контента переходят с почти нуля на более 1 с каждая.

Подробно смотрите здесь:

Все это слишком однообразно, чтобы совпадать.

iptables не предлагает никакого троттлинга. В конфиге nginx тоже ничего не изменилось, кроме включения SPDY. Поскольку это nginx 1.8.0, это тоже не ошибка tcp_nodelay. У меня нет специальных ограничивающих конфигураций в моих файлах conf или брандмауэре. keepalive_timeout - 75, а остальные параметры поддержки активности по умолчанию.

Где мне искать? Что я могу попробовать? В чем может быть проблема?

Поскольку сейчас может возникнуть проблема с пропускной способностью, одновременно загружается до 28 ресурсов, вот график использования пропускной способности. Загрузка загруженного JS происходит между 0,7 и 2 с. За исключением странного погружения в нос, пропускная способность достигает максимума (1,5 Мбит / с), поэтому, возможно, среда хостинга также имеет здесь какое-то влияние.

Я считаю, что то, что вы испытываете, согласуется с тем, как работает SPDY.

В «старом» HTTPS браузер будет посылать запросы на сервер последовательным образом, что вы и видите на своем первом снимке экрана.

Однако с SPDY все запросы отправляются одновременно, после чего сервер отвечает файлами в том порядке, который он считает оптимальным. Это то, что вы видите на втором снимке экрана - обратите внимание, что начало всех запросов происходит в один и тот же момент времени.

Порядок, в котором сервер доставляет запрошенные файлы, зависит от конфигурации сервера, но, что более важно, от приоритетов ресурсов. Идея состоит в том, чтобы отправить файлы JS и CSS заранее, чтобы сайт можно было раскрасить. После этого SPDY должен отправить изображения и другие ресурсы.

Потому что вы указываете, что время DOMContentLoaded и load не сильно отличается между SPDY и HTTPS, я думаю, ваш сервер работает правильно. Если вы хотите сократить время рисования, подумайте о расстановке приоритетов.

Источники и очень интересное дальнейшее чтение:

Как указано в комментариях ниже, JayMcTee обнаружил, что его конкретная ситуация была вызвана пропускной способностью - поскольку SPDY выполняет все запросы одновременно, пропускная способность будет легче заполняться, что приведет к более медленным отдельным запросам, чем при последовательном выполнении.