Тестирование продуктивности — вот самый точный перевод термина «performance testing».

Но чаще всего используется словосочетание «тестирование производительности«.

А еще чаще мы говорим «перформанс тестинг», чтобы не упариться с переводом.

Непорядок мирового порядка заключается в том, что под словом «перформанс» подразумевается очень много всякого. Например, выступление артистов на сцене — тоже перформанс. Но мы тут далеки от необходимости кого-то в чем-то убеждать.

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

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

Проверка продуктивности сайта

в принципе подразумевает следующее:

1. Эмулирование пользовательских запросов к тестируемому сайту на минимальных, средних, и максимальных величинах (которые должны быть определены ДО начала перформанс-тестинга).
   • Это называется испытание сайта в рабочих условиях, или максимально к ним приближенных.
2. Сравнение изначальных критериев оценки продуктивности функционирования сайта (чего хотели добиться) с реальными показателями (что получилось).

Критерии продуктивности

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

Критерии продуктивности должны быть:

• измеримыми,
• количественными,
• прогнозируемыми,
• понятными.

Пример критериев

1. при поиске профилей с фотографиями сервер должен «выдерживать» не меньше 150 одновременным запросов,
2. генерация страницы с результатами запроса не превышает 4 секунд,
3. результаты запросов кэшируются и выдаются очередному пользователю, который делает запрос, аналогичный предыдущему,
4. приложение «выдерживает» 600 активных пользователей.

Делая вид, что основываются на этой информации, веб-строители выбирают подходящие инструменты и программное обеспечение. Например, мы верим в то, что система управления базами данных MySQL выдерживает, не кашляя, 200 одновременных запросов. Точнее, принимает и ставит сукиных детей в очередь. Значит, «Для обеспечения 150 одновременным запросов на разрабатываемом приложении мы выбираем MySQL!» говорят веб-строители, а потом оказывается, что надо было сразу выбирать Berkeley, но «Боржоми» уже закончилось…

Иногда разработчики ничего особо не выбирают, а пользуются тем, что есть и чем они умеют управлять…

Тестировщиков проблема выбора веб-строителей не волнует. Тестировщиков волнует проверка продуктивности этого творения.

Что следует проверять

при перформанс-тестировании, уже придумано до и для нас:

1. Время отклика

   • В оригинале: Response time.
   • Измеряется в секундах время между исходным запросом к серверу и его «окончательным» ответом клиенту во всех рабочих режимах — как в режиме нормальной нагрузки, так и в усиленном режиме, когда перегорают сразу все UPS в здании.

2. Максимально допустимая нагрузка

   • В оригинале: Load testing.
   • Просто последовательно увеличиваем нагрузку с нуля до «допустимых» параметров.
   • Основной вопрос, на который мы пытаемся ответить посредством лоад-тестинга: «Как изменяется время отклика при увеличении нагрузки на сервер — линейно или по-дурацки?»
     • Линейно: если время отклика растет пропорционально увеличению нагрузки. Это нормально.
     • По-дурацки: если время отклика растет непропорционально увеличению нагрузки. Начинаются задумчивые, непрогнозируемые, неконтролируемые «тормоза».
       • Иногда вместо «по-дурацки» говорят «логарифмически». Пример: «Время отклика растет логарифмически!»
       • Лично еще не встречал человека, который мог свободно и уместно использовать этот термин.
   • Уточнение: лоад-тестинг является составной частью всеобщего перформанс-тестинга.

3. Максимально выдерживаемая нагрузка

   • В оригинале: Stress testing.
   • Делаем то же самое, что и при load testing, просто не останавливаемся, когда доходим до предполагаемых пределов. Продолжаем увеличивать нагрузку. Доводим сервачок до истерики. Получаем информацию о том, как он себя поведет, когда нагрузка превысит расчетные нормы. Узнаем, до каких масштабов сервер (ну, или приложение) будет стараться работать, и на каких значениях оно откажется нам служить.
   • Таким образом, разница между Load и Stress testing в перформансе очень субъективна, грань тонка, а со стороны вообще не разобрать, что происходит — просто сидит человек перед компьютером… В действительности разница в том, что Load приносит нам информацию о поведении приложения «в рамках ожидаемого», а stress приносит нам информацию о поведении приложения при пересечении этих «рамок».

4. Время отклика

   • В оригинале: Response time.
   • Измеряется в секундах время между исходным запросом к серверу и его «окончательным» ответом клиенту во всех рабочих режимах — как в режиме нормальной нагрузки, так и в усиленном режиме, когда перегорают сразу все UPS в здании.

5. Среднее время наработки на отказ

   • В оригинале: Mean time to failure (MTTF).
   • Разработчики клянутся в том, что при нагрузке в 300 активных пользователей сервер «будет беспроблемно жить в течение часа, пока кэш не переполнится».
     • Тестировщики начинают подсчитывать: час — 300 юзеров. Значит, 600 юзеров «убьют» приложение за полчаса. А 1200 юзеров убьют сервер моментально!
     • Или нет: час = 300 юзеров. А если два часа держать сервер под этой нагрузкой? А если три? А если шесть часов держать сервер под таким массивом запросов — он рухнет? Нет? Давайте проверять.
     • А давайте узнаем, сколько времени будет «безотказно» работать сервер с базой данных отдельно от сервера с приложением! А процессор не перегреется?
   • В общем, на основе собственных знаний, инженеры предполагают, что в течение недели сервер будет «стабильно» жить под пиковой нагрузкой в 300 запросов в течение часа. Нормально? Это предсказывали? Это и проверили?
   • Для тестирования веб-серверов MTTF может и не быть очень важной проверкой. Если сдох — ну, ребутнём его… Но, например, без тестирования на MTTF систем, которые будут работать далеко от разработчиков (в космосе), фэйл может быть буквально трагичным.

6. Настройка продуктивности

   • В оригинале: Performance tuning.
   • Звучит странно, но тут действительно подразумевается конечная подстройка производительности тестируемого сервера. Тестировщики СОВМЕСТНО с разработчиками настраивают и в сотый раз перепроверяют работу сервера с учетом сделанных изменений. Сами по себе тестировщики здесь беспомощны.

   • В тысячный раз увеличивается нагрузка на сервер до тех пор, пока все «узкие места» не объявлены «выявленными и ликвидированными». Или «выявленными, но признанными недопустимыми».

Инструменты для тестирования продуктивности

Бесплатные

• Apache JMeter
• Grinder
• WebLoad
• Microsoft Web Application Stress Tool
• OpenSTA
• QEngine

Платные

• NeoLoad
• LoadRunner
• Rational Robot, Rational Performance Tester
• SilkPerformer
• AQtime
• PureLoad
• QALoad

Если много свободного времени

1. Читаем тоже общую, но толковую статью «Описание подхода к тестированию производительности ПО«:

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

2. Читаем двухсотстраничный Performance Testing Guidance (pdf) из лабораторий Microsoft за авторством
   1. J.D. Meier
   2. Carlos Farre
   3. Prashant Bansode
   4. Scott Barber
   5. Dennis Rea

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

Предполагается

1. Наличие JMeter, или Siege, или ApacheBenchmark, или любую другую подобную утилиту, тестировщик уже освоил.
2. что выбранная для применения утилита установлена на всех тех компьютерах, которые будут «мочить» сервер
3. что тестировщик умеет лично перебегать между компутерами (или теребить коллег) и поочередно запускать с них JMeter-атаки.
4. что на всех задействованных в этом тестировании компьютерах созданы профили с идентичными логином и паролем. Например, testuser/testpass. Кто этого не сделает, тому все равно придется это сделать, а причину я объясню чуть позже.

Теперь сюрприз: что существенно облегчит перебежки тестировщика между компутерами?

Правильно, существенно облегчит перебежки тестировщика между компутерами утилита Cluster SSH. А также любая Ubuntu.

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

Установка (на добро)

Открываем терминал:

sudo apt-get install clusterssh

Y, разумеется, Y!

Пока ставится, открываем еще одно терминальное окно (позже будет удобно), и пишем команду, которая создает файл с конфигурацией cssh — starting the utility will be much faster with a configuration file (as this prevents searching for required files):

sudo cssh -u > /home/user/.csshrc

В справке путь указан как $HOME. Если у вас домашняя директорая иная, нежели /home/user/, пишите иное.

Запускаем в этом же (втором) терминалике Midnight Commander с правами root (да не убий Убунту):

sudo mc

В левой панели ищем /home/user/.csshrc и открываем его. Внимательно смотрим содержимое. Внимательно закрываем содержимое, бо нефиг его трогать. Повторять до просветления.

В правой панели переходим в ‘etc/’. Там рожаем файл clusters:

>clusters

Открываем этот файл на исполнение, и вписываем в него IP компьютеров, на которых располагается наше оружие (JMeter, например):

host1 = user@192.168.1.32

host2 = marin@192.168.1.36

host3 = boss@192.168.1.200

stressit = host1 host2

stressitall = host1 host2 host3

Не спеша прочитав, слушаем внимательно.

host1

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

user@192.168.1.36

‘user’ — это имя пользователя на удаленной машине, которых мы заранее завели перформанс-теста ради. Если юзера там зовут ‘Petea’ — пишем в нашем файле ‘Petea’.

‘192.168.1.36’ — это IP. Как круто это знать. IP вам выдаст администратор вашей сети, под пытками с применением пива и пиццы. В общем, как договоритесь.

При первом подключении к удаленным компьютерам CSSH выдаст предупреждение и вопрос, мол, ‘вы точно хотите подключиться к еще неизвестному мне компутера?’ Придется сказать Yes. Зато потом утилита уже будет знать, что мы ломимся к удаленному компу под указанным нами пользователем, и будем спрашивать только пароль входа.

stressit

‘stressit’ — это произвольное сочетание букв, это тэг, который будет распознавать CSSH. Тэг говорит утилите — мы хотим запустить наши руки в компы, которые у тебя прописаны под host1 и host2. Имя тэга зависит только от ваших сексуальных предпочтений. Как хотите, так его и назовите. Я назвал его ‘stressit’, и ничуть не сожалею об этом.

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

‘stressitall’ — это пример другого тэга, который говорит: мы убиваем сервер, сразу абсолютно все наши компы. Почему все? Потому, что для этого тэга я указал абсолютно все наличные в файле ‘host’ — и host1, и host2, и host3. Было бы 100 хостов — пришлось бы прописать их всех. Но сейчас у меня под рукой только три копмьютера, поэтому такая запись в файле ‘clusters’.

Кстати, мы же создали на всех компах тестовых юзеров-пустышек? Значит, наш файл ‘clusters’ выглядит так:

host1 = user@192.168.1.36

host2 = user@192.168.1.37

host3 = user@192.168.1.200

stressit = host1 host2

stressitall = host1 host2 host3

‘MC’ можно закрыть.

Запускаем cssh

В терминал:

sudo cssh stressit

С правами root мы открываем cssh и повелеваем ей запустить именно те хосты, которые прописаны в файле ‘clusters’ под тэгом ‘stressit’.

В терминале для каждого хоста пишут угрозы типа — WARNING: unknown host = (see -i switch, or ignore_host_errors in .csshrc) — ignoring. Их можно игнорировать. Лезть в конфиг-файл и говорить Yes для опции ignore_host_errors не рекомендуется.

При первом подключении к удаленному компьютеру в консоли cssh должен появиться вопрос, мол, вы стукаетесь на такой-то компьютер. Он неизвестен. Вы уверены, что надо к нему подключиться?

Надо полностью написать слово «yes».

Ответ cssh — Warning, permanently added такой-то IP to the list of known hosts, и при последующих запусках этого вопроса не будет. Будет сразу приглашение ввести пароль для доступа. Что нам и нужно.

Теперь предлагаю поэкспериментировать с утилитой. Можно всякие ее немногочисленные опции подергать. Закрыть и снова запустить.

Можно добавить еще один (или сто) хост по рецепту user@server. Но в принципе — нечего тут дергать, если мы уже все прописали в файле ‘clusters’.

Если ковыряние завершено, запускаем утилиту по-серьезному. Откроем два компутера которые у нас под тэгом stressit записаны. В терминал:

sudo cssh stressit

Видим:

Окна я сам расположил равномерно.

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

Тем не менее, через это поле будем посылать команды во все открытые сеансы (на все компьютеры).

Прошу знать

• если команду нужно выполнить только для одного сервера, обратитесь к нужному окну терминала.
• Чтобы исключить сеанс из перечня массового выполнения команд, нужно снять соответствующий флажок в меню ‘Hosts’ в основном окне утилиты.
• Чтобы исключить все сеансы сразу, используйте команду ‘Toggle active state’ — в основном окне. Применив ее — не жалуемся, сеансы действительно отключаются.
• Для упорядочивания окон на экране применяем команду ‘Retile’.
• Справка по программе есть и в меню Help — Documentation, и в консоли — man cssh, и на sourceforge.net.

Все запущено, в основном окне в поле ввода мигает курсор.

Сходу пишем пароль для доступа к удаленным юзерам. Он, по правилам юникс, не отображается. Пишем пароль, жмем «Enter» — хо-хо мы получили доступ!

Для разгона впишем команду ‘ls’. Вот теперь отлично видно все, что пишем — это отображается сразу во всех открытых консолях.

Рулез!