Как интерпретировать результаты осады и / или Apache Bench

Question

У нас есть сайт, управляемый MySQL, который в течение 48 часов может время от времени получать 100 000 пользователей, заходя на сайт и совершая покупки.

Мы пытаемся смоделировать этот вид нагрузки с помощью таких инструментов, как Apache Bench и Siege.

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

Что я хочу спросить: что мы должны тестировать, чтобы предвидеть такой трафик?

50 одновременных пользователей 1000 раз? 500 одновременных пользователей 10 раз?

Мы смотрим на ошибки БД, тайм-ауты Apache и время отклика. На что еще мы должны смотреть?

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

Заранее спасибо!

Answer 1

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

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

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

Что касается показателей на стороне сервера, какие еще технологии используются в вашем приложении? Вы захотите взглянуть на разные вещи для приложения .NET по сравнению с приложением PHP.

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

Answer 2

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

База данных, как правило, является критически важной частью инфраструктуры, поэтому я бы посмотрел на запись количества и продолжительности ожидания блокировки, а также количества и продолжительности операторов db.

Еще один ключевой момент, на который стоит обратить внимание - это длина очереди диска.

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

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