Библиотека сайта rus-linux.net
Высокопроизводительный сетевой стек Chrome
Глава 1 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: High Performance Networking in Chrome
Автор: Ilya Grigorik
Перевод: А.Панин
Что значит "достаточно быстро"?
Затраты времени на опрос серверов DNS, рукопожатия и обращения данных преобладают в описанной нами ситуации - время подготовки ответа сервером составляет только 20% от общего времени задержки. Но важны ли в целом эти задержки? Если вы читаете эту главу, то наверняка знаете ответ на данный вопрос: да, причем очень.
Проведенные исследования пользовательских качеств приложений позволяют составить четкое представление о том, что мы, как пользователи ожидаем в плане отзывчивости от любого приложения, как локального, так и сетевого:
Задержка | Реакция пользователя |
---|---|
0 - 100 мс | Мгновенное открытие |
100 - 300 мс | Небольшая воспринимаемая задержка |
300 - 1000 мс | Машина работает |
Более 1 с | Психологическое переключение контекста |
Более 10 с | Зайду сюда позже... |
Таблица 1.1 также описывает неофициальное требование, предъявляемое к производительности веб-приложения участниками сообщества разработчиков: следует выводить страницы, или в крайнем случае видимые сообщения примерно после 250 мс для того, чтобы пользователь не потерял интереса. Это не просто скорость ради скорости. Исследования, проведенные компаниями Google, Amazon, Microsoft, а также тысячами других сайтов говорят о том, что дополнительная задержка непосредственно влияет на популярность вашего сайта: более быстрые сайты имеют большее количество просмотров, привлекают большее количество пользователей и характеризуются более высокими показателями.
Таким образом, мы получили наш оптимальный показатель времени задержки в 250 мс и, как мы увидели в приведенном выше примере, комбинация из задержек опроса DNS-серверов, рукопожатий TCP и SSL, а также периодов отправки данных составляет 370 мс. Наш оптимальный показатель превышен на 50% и это с учетом того, что мы не учли время подготовки ответа сервером.
Для большинства пользователей и даже веб-разработчиков задержки для работы с серверами DNS и протоколами TCP и SSL представляются как операции на уровнях сетевого стека, о которых могут рассуждать только избранные. Однако, каждый из этих шагов является критичным для общих пользовательских качеств программного продукта, так как каждый дополнительный сетевой запрос может привести к дополнительным десяткам или сотням миллисекунд задержек. Это причина, по которой сетевой стек Chrome является гораздо более сложной системой, чем простой механизм для работы с сокетами.
Теперь, когда мы установили проблему, давайте разберемся с деталями реализации.
Продолжение статьи: Сетевой стек Chrome с расстояния в 10000 футов.