19  /  96

Бэкэнд

Просмотров: 1679 (Статистика ведётся с 06.02.2017)

Приложение

Типичная схема работы веб-приложения состоит из следующих шагов:

  • Приложение и/или веб-сервер (php, java, perl, python, ruby и т.п.) - принимает запрос клиента;
  • Приложение обращается к БД и получает данные;
  • Приложение формирует html;
  • Приложение и/или веб-сервер - отдает данные клиенту.

Тут все понятно с точки зрения обеспечения скорости:

  • оптимальный код приложения, без зацикливаний на секунды;
  • оптимальные данные в БД, индексация, денормализация;
  • кеширование выборки из БД.

Главное одно - чтобы приложение было прозрачно и можно было измерить скорость прохождения запроса через разные компоненты приложения. Если этого нет - дальше можно не читать, не поможет.

Как этого добиться? Пути известны:

  • Стандартное логирование запросов (nginx, apache, php-fpm);
  • Логирование медленных запросов БД (опция в mysql);
  • Инструменты фиксации узких мест при прохождении запроса. Для php это xhprof, pinba;
  • Встроенные инструменты внутри веб-приложения, например отдельный модуль трассировки.

Если логов вас много и вы запутываетесь в них, то тогда следует агрегировать данные, смотреть процентили и распределение.
При обнаружении запроса более 0.3 секунд начинайте разбор полетов и так до победного конца.



Веб-сервер

В плане скорости тут может помочь "костылизация" - через установку обратного прокси-веб-сервера перед веб-сервером (fascgi-сервером).

Это помогает:

  • держать значительно больше открытых соединений с клиентами (за счет другой архитектуры кеширующего прокси - для nginx это использование мультиплексирования сокетов небольшим числом процессов и низкого объема памяти для одного соединения)
  • более эффективно отдавать статические ресурсы напрямую с дисков, не фильтруя через код приложения

Постоянные соединения

Ключ к пониманию появления тормозов в следующей диаграмме:

Установление TCP-соединения занимает 1 RTT. Эта величина довольно тесно коррелирует с расположением вашего пользователя относительно веб-сервера (да, есть скорость света, есть скорость распространения света в материале, есть маршрутизация) и может занимать (особенно с учетом провайдера последней мили) - десятки и сотни миллисекунд, что конечно много. И беда, если это установление соединения происходит для каждого запроса, что было распространено в HTTP/1.0.

Ради этого по большому счету и затевался HTTP 1.1 и в этом направлении развивается и HTTP 2.0 (в лице SPDY ). IETF с Google в настоящее время пытаются сделать все, чтобы выжать из текущей архитектуры сети максимум - не ломая ее. А это можно сделать максимально эффективно используя TCP-соединения, используя их полосу пропускания как можно плотнее через мультиплексирование, восстановление после потерь пакетов и др.

Поэтому обязательно нужно проверить использование постоянных соединений на веб-серверах и в приложении.

TLS

Без TLS, который изначально зародился в недрах Netscape Communications как SSL - в современном мире никуда. И хотя, говорят, Последняя "дырочка" в этом протоколе заставила многих поседеть значительно раньше срока - альтернативы практически нет.

Но не все почему-то помнят, что TLS ухудшает "послевкусие" - добавляя 1-2 RTT дополнительно к 1 RTT соединению через TCP. В nginx вообще по умолчанию кеш сессий TLS - выключен, что добавляет лишний RTT.

Поэтому следует проследить, чтобы TLS-сессии в обязательном порядке кешировались, что позволит сэкономить еще 1 RTT (а один RTT все-таки останется, к сожалению, как плата за безопасность).



3
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии