Урок №3
Материал предоставлен командой DevOps компании ALG Systems.
Команда ALG DevOps Team будет благодарна за ответы на следующие вопросы:
В предыдущем уроке за кадром остались такие важные моменты при проведении нагрузочного тестирования, как анализ работы с внешними сервисами и базами данных. Сегодня мы как раз и обсудим эти вопросы.
Давайте посмотрим на архитектуру типичного приложения.
Картина, которую мы видим, отлично отражает работу современных корпоративных приложений – множество внешних сервисов, с которыми нужно взаимодействовать. Среди них скромно затесалась база данных, но не дайте себя обмануть – она играет одну из ключевых ролей в производительности приложения.
Запросы к базам данных
Все приложения, так или иначе, обращаются к базам данных. И даже без отдельного мониторинга самой базы данных, с помощью инструментации мы можем собирать данные об исполняемых SQL-запросах:
- Количество SQL-запросов. Отвечают на вопросы –
- Если количество SQL-запросов растет быстрее, чем количество пользователей, нет ли проблем с кэшированием результатов либо самими данными?
- Если при этом среднее количество SQL-вызовов у стандартного пользователя не меняется со временем, можно ли настроить грамотное кэширование результатов поиска?
- Самые медленные SQL-запросы. Отвечают на вопросы –
- Можно ли оптимизировать некоторые из этих запросов на уровне кода?
- Есть ли частые медленные запросы, которые можно ускорить, добавив новые индексы?
- Есть ли возможность кэшировать данные каких-либо тяжелых запросов?
- Самые частые SQL-вызовы. Отвечают на вопросы –
- Нет ли признаков «проблемы N+1 запроса» (неоптимальной работы с базой данных)?
- Есть ли возможность кэшировать данные, которые запрашиваются очень часть?
Например, глядя на это распределение, сразу заметны повторяющиеся паттерны вызовов, и уже детальное их изучение сможет определить путь улучшения производительности приложения.
Пулы соединений к БД
Поскольку установка соединения с сервером БД далеко не самый быстрый процесс, для ускорения доступа к базам данных приложения используют заранее подготовленные пулы соединений. Различного рода утечки соединений, длительное удерживание выданного соединения, а также неправильный размер пулов могут привести к серьезным проблемам с производительностью.
На что стоит обращать внимание:
- Утилизация пулов. Отвечает на вопросы –
- Достаточен ли объем пулов при обычной работе, нет ли истощения (утечек)?
- Что происходит при увеличении нагрузки, выдержат ли пулы ожидаемую предельную нагрузку?
- Время получения соединения. Отвечает на вопросы –
- Насколько точно подобрана конфигурация и количество соединений в пулах?
- Связано ли увеличение времени на получение соединения из пула с тем, что нет свободных соединений, и нужно ли изменить конфигурацию?
В качестве примера покажем график периодического истощения соединений.
В приложениях с давно изученными профилями нагрузки можно достичь некоего идеала конфигурации пулов. При этом могут возникать моменты, когда количество свободных соединений стабильно минимально, но при этом транзакции не страдают. Но это скорее исключение из правила.
И в реальных условиях, если вы наблюдаете постоянное истощение свободных соединений, можно смело констатировать наличие проблем и потерю продуктивности.
Обращения к прочим внешним сервисам
Все возможные внешние сервисы не перечислить, да и детально рассказывать о каждом вовсе не требуется. Работа с ними в подавляющем большинстве случаев ведется по API. И главное для успешного траблшутинга – хорошо представлять работу приложения и причины обращения к внешним сервисам, и что может пойти не так. И собирать информацию о ключевых метриках.
Как минимум, требуются данные о количестве обращений и времени отклика, пулах соединений и времени ожидания соединения, возникающих ошибках и снапшоты на момент ошибки.
Завершая урок, хотим отметить, что все это время мы смотрели на происходящее «из амбразуры» – со стороны сервера приложений. Для получения полной картины работы приложения, необходимо ставить агенты и на серверы баз данных, и на прочие внешние сервисы. Это позволит видеть происходящее за границами нашего сервера и коррелировать события, осуществлять полноценный траблшутинг и оптимизацию работы приложений.
