Нагрузочное тестирование веб-приложения - PullRequest
6 голосов
/ 30 июля 2010

При нагрузочном тестировании базового веб-приложения какие проверки работоспособности вы проводите, кроме ожидаемого времени ответа?
Справедливо ли запрашивать пиковое использование памяти?
Какие еще чеки вы делаете?

Ответы [ 4 ]

7 голосов
/ 30 июля 2010

на сервере

  • запросов в секунду, которые может выдержать приложение
  • Количество запросов в секунду, попадающих в базу данных (если есть, связанных с указанным выше числом, но полезно иметь их как отдельные цифры)
  • Переданная полоса пропускания (по возможности, по типу носителя)
  • загрузка процессора
  • Использование памяти

На клиенте

  • Время отклика
  • Вес средней страницы
  • Высокая загрузка ЦП в любое время
  • Запустите что-то вроде YSlow, чтобы увидеть, что вы можете оптимизировать для вывода, чтобы сделать его быстрым для пользователей

Инструменты стресс-тестирования обычно поставляются с большинством из этих мер (за исключением использования памяти, процессора и базы данных), как это делают YSlow или Firebug на клиенте.

3 голосов
/ 31 августа 2010

При анализе результатов нагрузочного теста мы смотрим на довольно широкий спектр показателей.

На сервере мы начинаем с следующих четырех основных категорий:

  • CPU (% использования, переключение контекста / сек, длина очереди процесса)
  • Память (использование%, чтение страниц / сек, запись страниц / сек)
  • Пропускная способность (входящие, исходящие, ошибки отправки и получения,# соединения, сбои соединения, повторная передача сегмента / сек)
  • Диск (время ввода-вывода диска%, среднее время обслуживания, длина очереди, чтение и запись / сек)

Мы такжеНапример, посмотрите на показатели, специфичные для используемого веб-сервера и сервера приложений.Например, в IIS мы рассматриваем количество подключений IIS, частоту обращений к кэшу и частоту оборотов и т. Д. В .NET мы будем рассматривать запросы ASP.NET / сек, время выполнения последнего запроса ASP.NET, текущие запросы ASP.NET, Запросы в очереди ASP.NET, время ожидания запросов ASP.NET, ошибки ASP.NET / сек и многие другие.

На стороне клиента мы в первую очередь смотрим на общее время загрузки страниц, продолжительность и TTFB.(время до первого байта) для критических транзакций, использования полосы пропускания, среднего размера страницы и частоты отказов.Мы также находим две метрики очень полезными - мы называем их «Ожидание пользователей» и «Среднее время ожидания».Не у многих инструментов они есть - они сообщают вам в каждом периоде выборки, сколько именно симулированных пользователей находятся в процессе извлечения ресурса с сервера и сколько времени в среднем они ожидают поступления ресурса.Мы находим их очень полезными для

  • определения, когда сервер достиг своей емкости
  • , обнаружив, что сервер перестал отвечать на определенные типы запросов (обычно для определенных ресурсов, таких кактребуется запрос к базе данных)
1 голос
/ 19 января 2012

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

1 голос
/ 05 января 2012

Еще одна хорошая проверка работоспособности - запускать тесты не менее 24 часов.Мы делаем это потому, что одно приложение работало в течение нескольких часов, а затем ухудшилось.Обнаружены некоторые проблемы с запланированными задачами, а также с пулом соединений с БД.

...