Контролируем производительность веб-решения

Производительность веб-решения – одна из ключевых метрик, контроль за которой ведется с помощью описанных выше средств автоматического мониторинга.

Обычно отслеживаются:

• Скорость отдачи основных веб-страниц сайта. Если она выше нескольких секунд – отправляется уведомление.
• Сколько процессов веб-сервера используются (например, 50 из 50 workers apache). В этот момент запросы клиентов веб-сайта выстраиваются в очередь и время обслуживания возрастает.
• Число потоков, которые обрабатывают запросы в базе данных. Если оно выше установленного показателя N, база данных перегружена и будет выполнять запросы гораздо медленнее. N выбирается в зависимости от оборудования и рекомендаций встроенных в продукт инструментов аналитики производительности MySQL.
• Число запросов в базе данных, которые выполняются дольше 1 секунды. Рост этого показателя говорит об увеличении нагрузки на MySQL – нужно искать причину.

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

Задачи по улучшению производительности необходимо решать вместе с подразделением разработки. Многие проблемы в равной степени зависят как от кода, так и настроек программного обеспечения и операционной системы.

  Отказоустойчивость

При аварии сработает служба мониторинга. Сотрудники подразделения эксплуатации восстановят веб-систему в разумное время: часы, дни.

Если требуется уменьшить данную метрику, например, чтобы простой не превышал 1 часа, и снизить вероятность внезапных кратковременных отказов, необходимо развернуть кластерную конфигурацию – она доступна «из коробки».

Тогда выход из строя одного из серверов (кроме mysql-master) не повлечет отказа всего веб-проекта. Одновременное падение более 1 сервера в кластере – крайне маловероятная ситуация. Но даже если она произойдет, ничего «страшного» – будет простой, в течение которого сотрудники эксплуатации восстановят работоспособность веб-решения.

Для автоматической реакции на отказ mysql-master-сервера пишут скрипт, который переключает веб-системы на один из актуальных mysql-slave-серверов.

Для размещения веб-проекта желательно использовать дата-центр категории не ниже Tier3. Чтобы еще больше повысить отказоустойчивость, можно разнести серверы по двум и более дата-центрам. Это технически доступно «из коробки» – называется Географический веб-кластер Настройка master-master репликации аналогична настройке master-slave репликации за исключением некоторых моментов...

Подробнее ... .

  Масштабирование проекта

При использовании редакции Веб-кластер масштабировать проект "1С-Битрикс: Веб-кластер" дает возможность гибко в реальном времени масштабировать именно те ресурсы (база данных или веб-сервер), которые востребованы в настоящий момент, просто добавляя новые машины по мере необходимости...

Подробнее ... под конкретную нагрузку не составляет труда – можно добавить сервер любой роли и увеличить производительность узла.

Для полноценного управления масштабированием рекомендуется:

• Вовремя реагировать на автотесты по производительности
• Вручную добавлять мощности в соответствующие узлы
• Собирать аналитическую информацию, как растет использование оборудования. Это делается с помощью популярных инструментов: Munin, Cacti и аналогичных

Прежде чем использование оборудования достигнет лимита в 70% (допустим, нагрузка на CPU на веб-сервере составляет 71% в пики и увеличивается из недели в неделю), следует добавить еще один веб-сервер. Не стоит дожидаться внезапной перегрузки текущей машины.

Похожий подход используется при подготовке к масштабным маркетинговым акциям – проверяется нагрузка на подсистемы на графиках munin, cacti в аналогичные периоды и делается вывод, сколько и какого оборудования следует добавить в веб-кластер.

Рекомендуем использовать скрипты, которые выполняют масштабирование автоматически. Такие возможности предоставляют популярные облачные провайдеры. Например, сервис «Auto Scaling» в Amazon Web Services.

  Тестирование и QA (quality assurance)

При ошибках в работе веб-проекта, в том числе тех, о которых сообщают посетители, необходима плотная работа с подразделением тестирования.

Работа с ошибками (багами):

1. Каждую ошибку нужно зарегистрировать, присвоить ей номер.
2. Баг необходимо исправить.
3. Сделать все, чтобы ошибки такого рода больше не появлялись.

Например, клиент сообщает о странной ошибке на сайте на английском языке: «Order not found. Assert kl == km failed». После ее исправления нужно убедиться, что в регламенте подразделения разработки появился пункт о стандартном сообщении об ошибках и что разработчики с ним ознакомились. При частых ошибках, которые связаны с интерфейсами и версткой, рекомендуется разрабатывать автотесты, использующие Selenium.