> Показатель TTFB (time to first byte) при отсутствии каких-либо тормозов
на сервере должен быть около двух задержек (rtt) от сервера к клиенту.
Но если в этот показатель включается время ssl-ного хендшейка, то он может
быть существенно выше, т.к. включает тяжёлую криптографию и зависит от
скорости шифрования на клиенте и на сервере. Как измеряется этот TTFB
и каково реальное значение rtt?
Измеряется при помощи DeveloperTools в Chrome.
Вот скриншот
https://i.snag.gy/XSY3Rm.jpg
rtt, если замерять пингом сейчас при размере пакета 56 байт:
64 bytes from xx.yy.zz.ww: icmp_seq=0 ttl=51 time=12.021 ms
64 bytes from xx.yy.zz.ww: icmp_seq=1 ttl=51 time=11.656 ms
64 bytes from xx.yy.zz.ww: icmp_seq=2 ttl=51 time=13.301 ms
64 bytes from xx.yy.zz.ww: icmp_seq=3 ttl=51 time=13.470 ms
64 bytes from xx.yy.zz.ww: icmp_seq=4 ttl=51 time=12.245 ms
(в данный момент замеры не внутри локальной сети, а по интернету, однако вообще никакой разницы в производительности не наблюдалось когда сервер nginx был в одной локальной сети (1Гб/с у обоих, клиента и сервера) с браузером)
>Вы пишете, что TTFB порядка 200-300 ms, а ниже, что заказчка целого файла
занимает целых 27 ms. Здесь явно противоречие, причём на порядок.
Здесь нюанс:
При 80 запросах - время закачки каждого из файлов по отдельности 1-1.5 сек.
При 1 единственном запросе - время закачки одного файла 23 ms (это тот же файл, к-ый присутствует в предыдущих 80-и запросах)
TTFB варьируется и это нормально - т.е. если не было файла в кэше, конечно TTFB будет больше (пока nginx заберёт файл с upstream или пока считает его с диска)
TTFB мы даже не рассматриваем, он вполне себе нормальный.
А вот доставка ответа от nginx до браузера феноменально тормознутая. При чём, как я говорил уже, без разницы в локальной сети nginx c браузером находится или нет.
> Какова получается скорость загрузки по http без ssl?
Без ssl время отдачи каждого запроса сократилось примерно на 50мс.
И сегодня большинство запросов уже по полсекунды обрабатываются, вместо вчерашней секунды! (при том что я не менял какие-то настройки)
Также я заметил есть пара файлов ( SVG картинки менее 1кб) - они стабильно грузятся 1 секунду (при том что точно берутся из кэша).
https://i.snag.gy/Yuczp3.jpg
> В дампе, при подозрении на потери в канале, прежде всего следует искать
пакеты с селективными подтверждениями (sack),
Сделал фильтр по tcp.options.sack.count - Wireshark показал множество таких пакетов.
Скажем я снимал дамп секунд 10 (время загрузки титульной страницы сайта) и
за это время в дампе оказалось 285 пакетов с SACK из 2284 суммарно.
Что с этим можно сделать?
>Разумеется, нужно убедиться, при tcp-шном хендшейке что обе стороны
договорились эту опцию использовать.
handshake’а нет в этом дампе, смогу написать несколько позже о том, что происходит нём.
