Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

Высокопроизводительный сетевой стек Chrome

Глава 1 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: High Performance Networking in Chrome
Автор: Ilya Grigorik
Перевод: А.Панин

Что значит "достаточно быстро"?

Затраты времени на опрос серверов DNS, рукопожатия и обращения данных преобладают в описанной нами ситуации - время подготовки ответа сервером составляет только 20% от общего времени задержки. Но важны ли в целом эти задержки? Если вы читаете эту главу, то наверняка знаете ответ на данный вопрос: да, причем очень.

Проведенные исследования пользовательских качеств приложений позволяют составить четкое представление о том, что мы, как пользователи ожидаем в плане отзывчивости от любого приложения, как локального, так и сетевого:

Таблица 1.1 - Восприятие задержек пользователем
Задержка Реакция пользователя
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 футов.

Поделиться: