Серверная архитектура и настройки ПО

Типовые ошибки:

• неоптимальное распределение нагрузки между серверами
• хранение сессий в БД
• недостаточный объем памяти для хранения сессий и кэша проекта
• некорректные настройки nginx, apache, php, opcache, memcache, MySQL

  Отсутствие мониторинга

Отсутствие корректно организованной системы мониторинга приводит к сложностям в определении реальных причин проблем проекта и лишним трудозатратам на устранение несущественных проблем. Что нужно контролировать:

• время выполнения страниц и важных целевых показателей
• динамику изменения основных целевых показателей
• общий мониторинг систем и сервисов проекта

  «Тяжелый» frontend

Типовые проблемы frontend'а

• Подключение библиотек в шаблонах сайта на всех страницах проекта. Подключение библиотек должно осуществляться только при необходимости на конкретных страницах. Например, если на проекте сервис «Яндекс.Карты» используется только на некоторых страницах, то API сервиса некорректно подключать в шаблоне сайта для всех страниц.
• Большой вес страницы из-за наличия inline-скриптов, стилей или других объектов. Все объемные инлайновые стили и скрипты необходимо выделять в css/js файлы, что позволит уменьшить вес страницы и кэшировать их на клиентской стороне.
• Большой вес подключаемых на странице ресурсов, таких как изображения, стили и скрипты. Необходимо уменьшать размер изображений, сжимая их, перед загрузкой на сервер, а также избегать ситуаций, при которых подгружаются изображения не отображаемые пользователю. Рекомендуется использовать «ленивую» загрузку только видимых объектов.

  Интеграция с внешними сервисами

• Выполнение синхронных запросов к внешним сервисам. Синхронные запросы приводят к медленному открытию страниц и могут являться причиной полной недоступности проекта из-за внешних факторов, таких как сетевая доступность и т.п.
  Все запросы к внешним сервисам должны выполняться асинхронно и никак не затрагивать хиты пользователя. Оптимальной можно считать систему, в которой, при недоступности внешних сервисов, полностью сохраняется основная работоспособность и не изменяется время генерации страниц.
• Отсутствие частичных обновлений, когда при взаимодействии с внешними сервисами, обновляются только измененные записи. При обновлении записей важно обновлять только изменяемые поля конкретной сущности, а не всю сущность целиком.
• Использование прямолинейных стратегий обмена данными. Такие схемы могут приводить к деградации производительности и росту объема синхронизированных данных в единицу времени. Например, при регулярном обновлении остатков нет необходимости обновлять каждые пять минут товары с наличием > 1000 и средней скоростью продаж в сутки менее 100. Их достаточно обновлять раз в сутки.

  Архитектура проекта

• Чрезмерное усложнение проекта и решение простых задач нестандартными способами. Одним из частных усложнений является использование системы кэширования html-ответа с отслеживанием валидности созданного ранее кэша на основе nginx и ряда других сервисов. Данный подход усложняет программный код, архитектуру проекта и ведет к удорожанию разработки и поддержки проекта, а также увеличивает риск возникновения ошибок и повышает сложность их выявления.
  Использование композитной технологии в большинстве случаев полностью покрывает возможности вышеуказанной системы и работает стандартно «из коробки».
• Злоупотребление сторонними библиотеками для решения типовых задач. Сторонние библиотеки усложняют проект и повышают риск деградации производительности системы.

  Неоптимальные алгоритмы

При проектировании логики работы приложения необходимо учитывать особенности системы и физические законы. К примеру, частой ошибкой при построении меню в проектах со сложной структурой каталога и большим количеством элементов является пересчет количества элементов в момент выполнения компонента. В этой ситуации данные о количестве элементов оптимальнее получать из свойства раздела, предварительно выполнив пересчет для каждой секции отдельно на агентах или событиях.