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

Приведу 2 главных инструмента, которые мониторят и прогнозируют работоспособность системы под нагрузкой.

Нагрузочное тестирование

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

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

Пишем тест-кейс

Нам нужна последовательность запросов, которые совершает приложение или сайт, эмулируя действия пользователя. Для этого опишите пользовательский сценарий в продукте:

• Авторизация
• Открытие главной страницы
• Открытие каталога
• Открытие товара
• Добавление товара в корзину
• Фоновое обновление корзины
• Установка региона, города и адреса в корзине итд

Каждый шаг сценария подразумевает запросы к API и будет создавть нагрузку для сервера.

Проводим тест

Методика тестирования заключаеется в том, чтобы написать автотесты, сэмулировать нагрузку на сервер и зафиксировать результаты. В качестве инструмента я бы рекомендовал Apache JMeter, но есть Яндекс.tank и другие решения.

Начать тестирование можно с пяти повторов, зауская одновременно: 100, затем 200, 500, 750 и 1000 потоков обращений.

Каждый поток — запущенный текст-кейс, где последовательно выполняются его шаги.

Разумеется, интервалы между запросами живого человека будут больше чем последовательный расстерл сервера тестовыми запросами. 1 поток может быть равен 5 или 10 онлайн пользователей, в зависимоти от модели взаимодествия с продуктом. То есть, запуская тест в 100 потоков, мы эмулируем нагрузку, которую создают 500 онлайн-пользователей.

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

Измеряем результат

Отслеживаем метрики: абсолютное количество ошибок (шт), относительное количество ошибок (%), время выполнения теста (с), время отклика (мс).

Допустим, мы запустили 100 одновременных потоков и сценарий текст-кейса предполагает 20 обращений к серверу (т. е.100 потоков сгенерировали 2 000 запросов), тест прошел без ошибок за 10 секунд.

Тут же видно, что в районе 750 одновременно активных потоков, наблюдается появление ошибок доступа к серверу. Логи ошибок передаем разработке.

С работоспосбностью понятно, давайте изучим производительность — для этого смотрим на время отклика каждого метода API, к которому мы делаем запросы.

Таким образом вы найдете слабые места сервера, которые тормозят сайт и приложение, уберете лишние обращения к базе данных и оптимизируете работу всей системы.

Как повысить скорость и отказоустойчивость сервера

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

• Второй вектор — за счет вертикального прироста производительности железа серверов.

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

Система мониторинга — Health Monitoring System (HMS)

Крутой инструмент для уже запущенных проектов — круглосуточно и автоматически мониторит API на работоспособность и быстродействие, собирает логи, формирует отчеты о всех событиях и сигнализирует, если запросы мобильного приложения или сайта не обрабатываются, либо скорость ответа сервера упала.

В систему мониторинга рекомендую добавить баг-репорты, которые пользователи отправляют в техподдержку, плюс подтягивать отзывы из App Store и Google Play (например, через AppFollow или другие агрегаторы).

Таким образом в одном месте собираются серерные логи, данные автотестов и техподдержки, так быстрее находить взаимосвязи и причины сбоев.

Вишенка на торте — оповещения о внештатрных ситуциях через Telegram-чат или другой месенджер, либо СМС.

Пишите мне, если остались вопросы или оставьте заявку на handh.ru, если хотие внедрить нечто подобное у себя.

Система мониторинга предупреждает и помогает быстро купировать критические ситуции, сохраняет нервы, деньги и репутацию продукта.

Cкорость работы мобильного приложения или сайта

Качество разработки и выбранные технологии — тема отдельной заметки и сегодня мы их не рассматриваем.

Исходим из того, что приложение и сайт разработаны грамотно: с понятной архитектурой, кэшированием, асинхронной загрузкой, без костылей и тормозных сторонних компонентов (колхозных SDK или библиотек). Если не уверены в этом, обратитесь за кодревью в студию или к тимлидам, которым вы доверяете.

Измеряя скорость работы приложений, мы сталкиваемся тем, что не знаем мощности железа в клиенстком смартфоне, количество запущенных на нем приложений, качества интернет-соединения.

Нельзя буквально влиять на скорость отображения экрана в приложении, так как рендеринг зависит от системного планировщика и свободных ресурсов на устройстве пользователя. 

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

Для оптимизации остатается смотреть на время с момента получения данных от сервера (загрузили и распарсили) до отправки на отображение, рендеринг.

Итого, чем «тоньше» фронтэнд, чем меньше логики и вычислений ему делигируется, тем лучше. Поэтому решаюшую роль в скорости работы веб или мобильного приложения играет поставщик данных, то есть API.

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

Обсуждать спецификацию к API стоит еще на этапе дизайна продукта.

Если в нашем продукте экран загружается дольше 1-2 секунд — это повод перечитать эту заметку и заняться диагностикой.