We use it.

Pro:
- price;
- good general approach;
- easy to learn;
- enough load per license - you can emulate 2000 users per machine where WAPT is installed;
- has IP spoofing.

Contra:
- version 5 still has some open issues with network errors - sometime the reason of error is not clear;
- doesn't work with Flash and we need to create a emulation of GUI to load server side;

You can ask about trial version and try it, why not?

А нас тоже в Европу записали :D недавно.
+1, короче.

Привет, Олешка!

Что-то давненько тебя не было.

I'm sorry. :) работа, то-се, в общем, я очень рада вернуться, хоть и под другим логином. Не складывается у меня с ним что-то.

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

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

Фактически критерии успешности могут меняться в зависимости от требований бизнеса (например, конкуренты сделали быстрее чем у нас и теперь мы должны обойти конкурентов), а модель нагрузки постоянна. Она обусловлена логикой работы системы и пользовательскими предпочтениями. Если у нас только 10% пользователей присваивают теги письмам для фильтрации по тегам, то и через полгода - год это примерное процентное соотношение сохранится, если данная функциональность не будет изменена на более удобную или не будут проведены дополнительные "продвигающие" мероприятия. Но без дополнительных воздействий на манеру работы пользователей модель нагрузки практически не меняется.
...
Другой пример модели нагрузки. В крупной компании (100.000 пользователей) все приходят на работу в 9 часов и запрашивают почту с сервера. С 9 до 9:30 приходится пик нагрузки на почтовый сервер. Так вот, модель нагрузки будет включать в себя операцию по коннекту почтового клиента к почтовому серверу, а критерий успешности - 100.000 одновременных пользователей, максимальное время отклика не более 10 секунд. Для другой компании количество пользователей и время отклика системы может иметь другие значения, но модель нагрузки не изменяется, если другая компания имеет такой же режим работы.

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

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

Я, пожалуй, не соглашусь с тем, что статья бесполезна - для тех, кто впервые сталкивается с задачей нагрузочного тестирования, знание о том, что есть логи сервера и как их можно смотреть и анализировать, пригодится. Но у меня есть пара вопросов-комментариев по модели нагрузки, заявленной в статье:

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

Анализ Web-логов для построения модели нагрузочного тестирования (Часть 2)

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

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

А вот паузы в действиях пользователей для модели нужны, но эта линия статьи как-то не до конца развита в обсуждаемой статье при описании модели нагрузки.
Хотелось бы увидеть пример того, зачем они нужны. Как вариант, когда на основе анализа реальной нагрузки планируется количество виртуальных пользователей.

Скажем, в книге Менаске Д., Алмейда В. Производительность Web-служб. Анализ, оценка и планирование приводится такой расчет:

Задачей тестирования является измерение возможностей и производительности серверов приложений. Команда специалистов также желает убедиться в том, что время отклика приложения будет находиться в заданных границах в условиях реальной нагрузки. Тестируемая система - это web система по обслуживанию кредитов, рассчитанная на 100000 пользователей, которые смогут в ней выполнять основные операции с банковскими счетами: просматривать состояние счета, изменять персональную информацию, подавать заявки на получение кредита. Нагрузка системы указана числом конкурирующих пользователей. Бизнес-аналитик оценивает среднее количество конкурирующих пользователей как 1% от общего числа пользователей.

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

Пусть R - среднее время отклика приложений,
Xo - пропускная способность сервера
Nr - количество одновременных реальных пользователей
Nv - количество одновременных виртуальных пользователей
Учитывая, что пропускная способность и время отклика должны быть одинаковы при тестировании в реальных условиях, можно записать:
Xo = Nr / (R + Z)
Xo = Nv / (R + 0)
Отсюда: Nv / Nr = R / (R + Z)
Предположим, что нам надо достичь значения среднего времени отклика R = 2 c и Z = 20 c для реальных пользователей
Тогда: Nv = Nr * 2 / (2 + 20) = 1000 * 1/11 = 90.9 ~ 91
Таким образом, при тестировании необходимо использовать до 91 виртуальных пользователей.

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

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

А скажите, уважаемые тестировщики, не встречалось ли вам профильное высшее учебное заведение (обучавшее в прошлом или обучающее сейчас лично вас, или друзей, или коллег), которое включает в свою программу курс или спецкурс по теории нагрузочного тестирования? Например, по такой книге - Менаске Д., Алмейда В. "Производительность Web-служб. Анализ, оценка и планирование"? Если да, не откажите в любезности черкнуть пару строк в тему - кто читал, где, насколько полезно оказалось. Спасибо.

P.S. Можно и саму книгу обсудить заодно, если кто пользуется.

Поздравляю!