Быстрое веб-приложение

&lt;p&gt;При рассмотрении и оптимизации проекта обычно берут во внимание 2 слабо связанные технологически и социально части: фронтэнд и бэкэнд. И нередко забывают про третью ключевую составляющую - сеть. &lt;/p&gt; &lt;!-- &lt;br&gt; &lt;h2&gt;Бэкэнд&lt;/h2&gt; &lt;h4&gt;Приложение&lt;/h4&gt; &lt;p&gt;Типичная схема работы веб-приложения состоит из следующих шагов:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;Приложение и/или веб-сервер (php, java, perl, python, ruby и т.п.) - принимает запрос клиента;&lt;/li&gt; &lt;li&gt;Приложение обращается к БД и получает данные;&lt;/li&gt; &lt;li&gt;Приложение формирует html;&lt;/li&gt; &lt;li&gt;Приложение и/или веб-сервер - отдает данные клиенту.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Тут все понятно с точки зрения обеспечения скорости:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;оптимальный код приложения, без зацикливаний на секунды;&lt;/li&gt; &lt;li&gt;оптимальные данные в БД, индексация, денормализация;&lt;/li&gt; &lt;li&gt;кеширование выборки из БД.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Главное одно - чтобы приложение было прозрачно и можно было измерить скорость прохождения запроса через разные компоненты приложения. Если этого нет - дальше можно не читать, не поможет.&lt;/p&gt; &lt;p&gt;Как этого добиться? Пути известны:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;Стандартное логирование запросов (nginx, apache, php-fpm);&lt;/li&gt; &lt;li&gt;Логирование медленных запросов БД (опция в mysql);&lt;/li&gt; &lt;li&gt;Инструменты фиксации узких мест при прохождении запроса. Для php это xhprof, pinba;&lt;/li&gt; &lt;li&gt;Встроенные инструменты внутри веб-приложения, например отдельный &lt;a href=&quot;http://www.1c-bitrix.ru/products/cms/features/perfmon.php&quot;&gt;модуль трассировки&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Если логов вас много и вы запутываетесь в них, то тогда следует агрегировать данные, смотреть процентили и распределение. &lt;br&gt; При обнаружении запроса более 0.3 секунд начинайте разбор полетов и так до победного конца. &lt;/p&gt; &lt;br&gt;&lt;br&gt; &lt;h3&gt;Веб-сервер&lt;/h3&gt; &lt;p&gt;В плане скорости тут может помочь &quot;костылизация&quot; - через установку обратного прокси-веб-сервера перед веб-сервером (fascgi-сервером). &lt;/p&gt; &lt;p&gt;Это помогает:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;держать значительно больше открытых соединений с клиентами (за счет другой архитектуры кеширующего прокси - для nginx это использование мультиплексирования сокетов небольшим числом процессов и низкого объема памяти для одного соединения)&lt;/li&gt; &lt;li&gt;более эффективно отдавать статические ресурсы напрямую с дисков, не фильтруя через код приложения&lt;/li&gt; &lt;/ul&gt; &lt;h4&gt;Постоянные соединения&lt;/h4&gt; &lt;p&gt;Ключ к пониманию появления тормозов в следующей диаграмме:&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/1.png&quot; width=&quot;500px&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Установление TCP-соединения занимает 1 &lt;a href=&quot;http://en.wikipedia.org/wiki/Round-trip_delay_time&quot;&gt;RTT&lt;/a&gt;. Эта величина довольно тесно коррелирует с расположением вашего пользователя относительно веб-сервера (да, есть скорость света, есть скорость распространения света в материале, есть маршрутизация) и может занимать (особенно с учетом провайдера последней мили) - десятки и сотни миллисекунд, что конечно много. И беда, если это установление соединения происходит для каждого запроса, что было распространено в HTTP/1.0.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/2.gif&quot; width=&quot;500px&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Ради этого по большому счету и затевался HTTP 1.1 и в этом направлении развивается и &lt;a href=&quot;http://en.wikipedia.org/wiki/HTTP_2.0&quot;&gt;HTTP 2.0&lt;/a&gt; (в лице &lt;a href=&quot;http://ru.wikipedia.org/wiki/SPDY&quot;&gt;SPDY&lt;/a&gt; ). IETF с Google в настоящее время пытаются сделать все, чтобы выжать из текущей архитектуры сети максимум - не ломая ее. А это можно сделать максимально эффективно используя TCP-соединения, используя их полосу пропускания как можно плотнее через &lt;a href=&quot;http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1&quot;&gt;мультиплексирование&lt;/a&gt;, восстановление после потерь пакетов и др. &lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/3.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Поэтому обязательно нужно проверь использование постоянных соединений на веб-серверах и в приложении.&lt;/p&gt; &lt;h4&gt;TLS&lt;/h4&gt; &lt;p&gt;Без &lt;a href=&quot;http://ru.wikipedia.org/wiki/TLS&quot;&gt;TLS&lt;/a&gt;, который изначально зародился в недрах Netscape Communications как &lt;a href=&quot;http://ru.wikipedia.org/wiki/SSL&quot;&gt;SSL&lt;/a&gt; - в современном мире никуда. И хотя, говорят, &lt;a href=&quot;http://ru.wikipedia.org/wiki/Heartbleed&quot;&gt;Последняя&lt;/a&gt; &quot;дырочка&quot; в этом протоколе заставила многих поседеть значительно раньше срока - альтернативы практически нет.&lt;/p&gt; &lt;p&gt;Но не все почему-то помнят, что TLS ухудшает &quot;послевкусие&quot; - добавляя 1-2 RTT дополнительно к 1 RTT соединению через TCP. В nginx вообще по умолчанию кеш сессий TLS - &lt;a href=&quot;http://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl_session_cache&quot;&gt;выключен&lt;/a&gt;, что добавляет лишний RTT.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/4.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Поэтому следует проследить, чтобы TLS-сессии в обязательном порядке кешировались, что позволить сэкономить еще 1 RTT (а один RTT все-таки останется, к сожалению, как плата за безопасность). &lt;/p&gt; &lt;br&gt;&lt;br&gt; &lt;h2&gt;Сеть. Расстояние и пропускная способность сети&lt;/h2&gt; &lt;p&gt;Для типичного веб-приложения пропускная способность не особо важна (если только файлы не качать) - гораздо важнее lantency, т.к. делается много небольших запросов по разным соединениям и TCP-окно просто не успевает раскачаться.&lt;/p&gt; &lt;p&gt;И разумеется, чем дальше клиент от веб-сервера, тем дольше. Но бывает что нельзя иначе или трудно. Именно поэтому придумали:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;&lt;a href=&quot;http://ru.wikipedia.org/wiki/Content_Delivery_Network&quot;&gt;CDN&lt;/a&gt;&lt;/li&gt; &lt;li&gt;Динамическое проксирование (CDN-наоборот). Когда в регионе ставится, например nginx, открывающий постоянные коннекты на веб-сервер и терминирующий ssl. Понятно зачем? Именно - в разы ускоряется установление соединений от клиента с веб-прокси (хэндшейки начинают летать), а дальше используется прогретое TCP-соединение.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;Еще можно &lt;a href=&quot;http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/&quot;&gt;увеличить&lt;/a&gt; TCP’s initial congestion window - это нередко помогает, т.к. веб-страничка отдается одним набором пакетов без подтверждения.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/5.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;h4&gt;Пропускная способность&lt;/h4&gt; &lt;p&gt;TCP-окошко соединения должно разогнаться сначала. Если веб-страница загружается меньше секунды - окошко может не успеть увеличиться. Средняя пропускная способность сети в мире - немного превышает 3 МБит/с. Вывод - нужно передавать через одно установленное соединение как можно больше, &quot;разогрев&quot; его.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/6.png&quot; width=&quot;500px&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Помочь тут может мультиплексирование HTTP-ресурсов внутри одного TCP-соединения: передача нескольких ресурсов вперемешку как в запросе, так и ответе. Эту технику даже включили в стандарт, но недоописали и в итоге она не &lt;a href=&quot;https://tools.ietf.org/html/rfc2616#section-8.1.2.2&quot;&gt;взлетела&lt;/a&gt; (в chrome ее не так давно вообще убрали). Поэтому тут можно пока попробовать &lt;a href=&quot;http://ru.wikipedia.org/wiki/SPDY&quot;&gt;SPDY&lt;/a&gt;, ждать HTTP 2.0 или использовать-таки pipelining - но не из браузера, а из приложения напрямую.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/7.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;br&gt;&lt;br&gt; &lt;h2&gt;Фронтэнд&lt;/h2&gt; &lt;p&gt;Тема про известные вещи типа скорости рендеринга веб-страницы и размера изображений и JavaScript, порядка загрузки ресурсов и т.п. достаточно избита.&lt;/p&gt; &lt;p&gt;Если кратко ее затронуть, то необходимо кешировать ресурсы на стороне веб-браузера, но с головой. Кешировать 10МБ js-файл и парсить его внутри браузера на каждой веб-странице ни к чему хорошему не приведет. &lt;/p&gt; &lt;p&gt;Гораздо более острые подводные камни могут скрываться за достаточно новыми и бурно развивающимися сетевыми возможностями веб-браузера:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;&lt;a href=&quot;http://www.w3.org/TR/XMLHttpRequest/&quot;&gt;XMLHttpRequest&lt;/a&gt;;&lt;/li&gt; &lt;li&gt;Long Polling;&lt;/li&gt; &lt;li&gt;&lt;a href=&quot;http://www.w3.org/TR/eventsource/&quot;&gt;Server-Sent Events&lt;/a&gt;;&lt;/li&gt; &lt;li&gt;&lt;a href=&quot;http://www.w3.org/TR/websockets/&quot;&gt;Web Sockets&lt;/a&gt;.&lt;/li&gt; &lt;/ul&gt; &lt;h4&gt;XMLHttpRequest&lt;/h4&gt; &lt;p&gt;Это всем известный AJAX - способность браузера обращаться к внешним ресурсам по HTTP. С появлением &lt;a href=&quot;http://www.w3.org/TR/cors/&quot;&gt;CORS&lt;/a&gt; - начался совершенный &amp;quot;беспредел&amp;quot;. Теперь чтобы определить причину торможения, нужно лазать по всем ресурсам и смотреть логи везде.&lt;/p&gt; &lt;p&gt;Технология, несомненно, взорвала возможности браузера, превратив его в мощную платформу динамического рендеринга информации. Писать о ней нет смысла, тема многим известна. Однако стоит упомянуть про ограничения:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;отсутствие мультиплексирования нескольких &quot;каналов&quot; заставляет неэффективно и не полностью использовать пропускную способность TCP-соединения;&lt;/li&gt; &lt;li&gt;нет адекватной поддержки streaming (открытие соединения с последующим ожиданием), т.е. остается обращаться к серверу и смотреть, что он ответил.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/8.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Тем не менее, технология очень популярна и сделать ее прозрачной с точки зрения мониторинга скорости - несложно.&lt;/p&gt; &lt;h4&gt;Long Polling&lt;/h4&gt; &lt;p&gt;Как сделать веб-чат? Да, нужно как-то передавать со стороны сервера в браузер информацию об изменениях. Напрямую через HTTP - нельзя, не умеет. Только: запрос и ответ. Вот в лоб люди и решили: сделать запрос и ждать ответ, секунду, 30 секунд, минуту. Если что-нибудь пришло - отдать в ответ и разорвать соединение.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/9.jpg&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Куча антипаттернов и костылей - но технология очень широко распространена и работает всегда. Но, нагрузка на серверы при таком подходе - очень высока, и может сопоставляться с нагрузкой от основной посещаемости веб-проекта. А если обновления от сервера к браузерам распространяются часто - то может основную нагрузку превышать в разы.&lt;/p&gt; &lt;h4&gt;Server-Sent Events&lt;/h4&gt; &lt;p&gt;Тут открывается TCP-соединение с веб-сервером, не закрывается и через него сервер передает разную информацию в UTF-8. Нельзя, правда, бинарные данные передавать оптимально без предварительного Base64 (+33% увеличение в размере), но как канал управления в одну сторону - превосходное решение. Правда в не поддерживается Internet Explorer (см. пункт выше, который везде работает).&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/10.jpg&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/11.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Плюсы технологии в том, что она:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;очень проста;&lt;/li&gt; &lt;li&gt;не нужно после получения сообщения заново переоткрывать соединение с сервером.&lt;/li&gt; &lt;/ul&gt; &lt;h4&gt;Web Sockets&lt;/h4&gt; &lt;p&gt;Браузер &quot;хитрым&quot; способом через HTTP 1.1 Upgrade меняет &quot;тип&quot; HTTP соединения и оно остается открытым.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/12.jpg&quot; width=&quot;550px&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/13.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Затем по соединению в ОБЕ стороны можно начать передавать данные, оформленные в сообщения (frames). Сообщения бывают не только с информацией, но и контрольные, в т.ч. типа &quot;PING&quot;, &quot;PONG&quot;. Первое впечатление - снова изобрели велосипед, снова TCP на базе TCP.&lt;/p&gt; &lt;p&gt;С точки зрения разработчика - конечно, это удобно, появляется дуплексный канал между браузером и веб-приложением на сервере. Хочешь streaming, хочешь messages. Но:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;не поддерживается html-кэширование (работа происходит через бинарный framing-протокол);&lt;/li&gt; &lt;li&gt;не поддерживается сжатие, его нужно реализовать самостоятельно;&lt;/li&gt; &lt;li&gt;жутки глюки и задержки при работе без TLS - из-за устаревших прокси серверов;&lt;/li&gt; &lt;li&gt;нет мультиплексирования, в результате чего каждое bandwidth каждого соединения используется неэффективно;&lt;/li&gt; &lt;li&gt;на сервере появляется много висящих и делающих что-то &quot;гадкое с базой данных&quot; прямых TCP-соединений от браузеров.&lt;/li&gt; &lt;/ul&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/14.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;Как же отслеживать производительность Web Sockets? Со стороны клиента - сниффер пакетов WireShark, со стороны сервера и с включенным TLS - можно решить задачу через патчинг модулей для nginx, как вариант.&lt;/p&gt; &lt;br&gt; &lt;p&gt;Так что же лучше: XMLHttpRequest, Long Polling, Server-Sent Events или Web Sockets? Успех - в грамотном сочетании этих технологий. Например, можно управлять приложением через WebSockets, а загружать ресурсы с использованием встроенного кэширования через AJAX. &lt;/p&gt; &lt;br&gt;&lt;br&gt; &lt;h3&gt;Что теперь делать?&lt;/h3&gt; &lt;p&gt;Научиться измерять и реагировать на превышение заданных значений. Обрабатывайте логи веб-приложения, разбирайтесь с медленными запросами в них. Скорость на стороне клиента тоже стало возможным мерить благодаря &lt;a href=&quot;http://www.w3.org/TR/navigation-timing-2/&quot;&gt;Navigation timing API&lt;/a&gt;. Можно собирать данные по производительности в браузерах, отправлять их средствами JavaScript в облако, агрегировать в pinba и реагировать на отклонения. Очень полезное API.&lt;/p&gt; &lt;p&gt;&lt;img src=&quot;/images/hl-projects/develop/arch/15.png&quot; border=&quot;0&quot;&gt;&lt;/p&gt; &lt;p&gt;В результате вы найдете себя в окружении системы мониторинга типа &lt;a href=&quot;http://www.nagios.org/&quot;&gt;nagios&lt;/a&gt;, с десятком-другим автоматических тестов, на которых видно, что со скоростью работы вашей веб-системы все в порядке. А в случае срабатываний - команда собирается и принимается решение. Кейсы могут быть, например, такими:&lt;/p&gt; &lt;ul&gt; &lt;li&gt;Медленный запрос в БД. Решение - оптимизация запроса, денормализация в случае крайней необходимости.&lt;/li&gt; &lt;li&gt;Медленная отработка кода приложения. Решение - оптимизация алгоритма, кэширование.&lt;/li&gt; &lt;li&gt;Медленная передача тела страницы по сети. Решение (в порядке увеличения стоимости) - увеличиваем tcp initial cwnd, ставим динамический прокси рядом с клиентом, переносим серверы поближе&lt;/li&gt; &lt;li&gt;Медленная отдача статических ресурсов клиентам. Решение - CDN.&lt;/li&gt; &lt;li&gt;Блокировка в ожидании соединения с серверами в браузере. Решение - шардинг доменов.&lt;/li&gt; &lt;li&gt;Long Polling создает нагрузку на серверы, большую, чем хиты клиентов. Решение - Server-Sent Events, Web Sockets.&lt;/li&gt; &lt;li&gt;Тормозят, неустойчиво работают Web Sockets. Решение - TLS для них (wss).&lt;/li&gt; &lt;/ul&gt; &lt;br&gt;&lt;br&gt; --&gt;