21  /  96

Выводы

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

Что теперь делать?

Научиться измерять и реагировать на превышение заданных значений. Обрабатывайте логи веб-приложения, разбирайтесь с медленными запросами в них. Скорость на стороне клиента тоже стало возможным мерить благодаря Navigation timing API. Можно собирать данные по производительности в браузерах, отправлять их средствами JavaScript в облако, агрегировать в pinba и реагировать на отклонения. Очень полезное API.

В результате вы найдете себя в окружении системы мониторинга типа nagios, с десятком-другим автоматических тестов, на которых видно, что со скоростью работы вашей веб-системы все в порядке. А в случае срабатываний - команда собирается и принимается решение. Кейсы могут быть, например, такими:

  • Медленный запрос в БД. Решение - оптимизация запроса, денормализация в случае крайней необходимости.
  • Медленная отработка кода приложения. Решение - оптимизация алгоритма, кэширование.
  • Медленная передача тела страницы по сети. Решение (в порядке увеличения стоимости) - увеличиваем tcp initial cwnd, ставим динамический прокси рядом с клиентом, переносим серверы поближе
  • Медленная отдача статических ресурсов клиентам. Решение - CDN.
  • Блокировка в ожидании соединения с серверами в браузере. Решение - шардинг доменов.
  • Long Polling создает нагрузку на серверы, большую, чем хиты клиентов. Решение - Server-Sent Events, Web Sockets.
  • Тормозят, неустойчиво работают Web Sockets. Решение - TLS для них (wss).


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

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