Comments 8
Занимался (и занимаюсь) тестированием производительности веб-приложений, которые делает наша компания. Процедура не сильно отличается от описанной в статье, если коротко:
1) выделяем пользовательские последовательности действий (сценарии поведения)
2) группируем эти сценарии
3) определяем количество виртуальных пользователей (для достижения заданных целей - малая, средняя, высокая загрузка, исследование на максимально возможную загрузку системы - пиковая производительность и т.п.)
4) пишем тесты, выполняем.
инструментарий - опенсорсовский:
- генератор трафика - Apache JMeter
- для сбора информации о загрузке системы используется вывод команды top c соответствующими фильтрами, для последующего анализа - самописный лог-парсер (параллельно он еще вычисляет ряд статистических критериев, но об этом ниже)
Само по себе тестирование производительности - вещь хорошая, но в разовом исполнении оно дает только приблизительный результат (ну да, можно сказать, что "вот, мы сейчас обеспечиваем работу стольких-то пользователей"), наибольший интерес для нас представляет сравнение результатов подобного тестирования от версии к версии.
Подобное сравнение опирается на сбор:
* информации о загрузке процессора (частотная группировка, с фиксированным шагом - 0-2%б 2-4% и т.п.)
* информации об объеме расходуемой памяти (аналогично, частотная группировка)
* прочая информация (времена доступа к базе, и т.п. - все по частотам)
От релиза к релизу алгоритм предварительной обработки замеров не меняется (строится частотная диаграмма). Сравнение качественных изменений проводится Т-Стьюдент тестом (для этого нам и были нужны частотные выборки одинаковой длины). Ну а вычисленный коэффициент как раз и показывает, насколько значимо приложенеи поменяло свое поведение.
p.s.
в планах ввести практику обязательного прохождения приложением теста на производительность.
1) выделяем пользовательские последовательности действий (сценарии поведения)
2) группируем эти сценарии
3) определяем количество виртуальных пользователей (для достижения заданных целей - малая, средняя, высокая загрузка, исследование на максимально возможную загрузку системы - пиковая производительность и т.п.)
4) пишем тесты, выполняем.
инструментарий - опенсорсовский:
- генератор трафика - Apache JMeter
- для сбора информации о загрузке системы используется вывод команды top c соответствующими фильтрами, для последующего анализа - самописный лог-парсер (параллельно он еще вычисляет ряд статистических критериев, но об этом ниже)
Само по себе тестирование производительности - вещь хорошая, но в разовом исполнении оно дает только приблизительный результат (ну да, можно сказать, что "вот, мы сейчас обеспечиваем работу стольких-то пользователей"), наибольший интерес для нас представляет сравнение результатов подобного тестирования от версии к версии.
Подобное сравнение опирается на сбор:
* информации о загрузке процессора (частотная группировка, с фиксированным шагом - 0-2%б 2-4% и т.п.)
* информации об объеме расходуемой памяти (аналогично, частотная группировка)
* прочая информация (времена доступа к базе, и т.п. - все по частотам)
От релиза к релизу алгоритм предварительной обработки замеров не меняется (строится частотная диаграмма). Сравнение качественных изменений проводится Т-Стьюдент тестом (для этого нам и были нужны частотные выборки одинаковой длины). Ну а вычисленный коэффициент как раз и показывает, насколько значимо приложенеи поменяло свое поведение.
p.s.
в планах ввести практику обязательного прохождения приложением теста на производительность.
Правильный линк на генератор трафика Apache JMeter вот: http://jakarta.apache.org/jmeter/
(у вас побилось...)
(у вас побилось...)
Хочу отметить, что даже разовые прогоны позволяют узнать многое о системе, и не всегда дают только приблизительный результат. Есть еще немало параметров и метрик которые полезно знать прежде чем запускать систему.
Я бы еще посмотрел на результаты, пусть даже разовые, не только со стороны обеспечения количества пользователей или анализа загрузки программно-аппаратного комплекса, но и как на результаты дающие уверенность, что завтра мы сможем, в случае увеличения нагрузки на систему, оперативно отреагировать и поддерживать большее количество. В данном случае я говорю об одном из трех основных показателей производительности - масштабируемости.
Так же при единичном прохождении можно выявить как себя поведет система при нестандартных нагрузках, а главное посмотреть на восстанавливаемость системы после непредвиденных сбоев. Это тоже очень немаловажно.
А вы у себя проходите эти фазы нагрузочного тестирования?
Я бы еще посмотрел на результаты, пусть даже разовые, не только со стороны обеспечения количества пользователей или анализа загрузки программно-аппаратного комплекса, но и как на результаты дающие уверенность, что завтра мы сможем, в случае увеличения нагрузки на систему, оперативно отреагировать и поддерживать большее количество. В данном случае я говорю об одном из трех основных показателей производительности - масштабируемости.
Так же при единичном прохождении можно выявить как себя поведет система при нестандартных нагрузках, а главное посмотреть на восстанавливаемость системы после непредвиденных сбоев. Это тоже очень немаловажно.
А вы у себя проходите эти фазы нагрузочного тестирования?
идеи есть, и в частном порядке я эксперименты ставлю (учитывая, что сервисы работают под Tomcat, c восстанавливаемостью плохо, уж если Out of memory, то до рестарта). Но как постоянная практика - это на стадии введения.
Нестандартные нагрузки - исследование интересное, но в нашем сегменте рынка (intranet-сервисы, и слабонагруженные internet-приложения) не сильно пока востребованное.
Меня еще интересует работа системы длительное время при стабильной средней нагрузке (stability testing) - расход памяти, загрузка, скорость отдачи страниц
Нестандартные нагрузки - исследование интересное, но в нашем сегменте рынка (intranet-сервисы, и слабонагруженные internet-приложения) не сильно пока востребованное.
Меня еще интересует работа системы длительное время при стабильной средней нагрузке (stability testing) - расход памяти, загрузка, скорость отдачи страниц
Sign up to leave a comment.
Тестирование производительности ПО