Приложение в твоем смартфоне
Приложение в твоем смартфоне
Приложение в твоем смартфоне
Приложение в твоем смартфоне
13 ноября 2011 в 11:27

Tsung: Нагрузочное тестирование Web-приложений


Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.


Почему Tsung


Во первых это приложение бесплатно. Во вторых приложение написано на Erlang'e, что дает ему преимущество перед другими продуктами, в способности симулировать огромное количество одновременных запросов.

Установка


Для установки вам потребуется Linux дистрибутив, я использовал debian. Необходимо проделать следующую последовательность действий:
  1. apt-get install erlang
  2. apt-get install gnuplot-nox libtemplate-perl libhtml-template-perl libhtml-template-expr-perl
  3. Скачать последнюю версию tsung-1.4.1.tar.gz
  4. Распаковать tar -zxvf tsung-1.4.1 .tar.gz
  5. Установить ./configure && make && make install
  6. Также необходимо создать каталог с именем .tsung в root директории и конфигурационный файл tsung.xml внутри него (подробнее о нем ниже)

Вот и все установка завершена!

Настройка


Все настройки хранятся в xml файле tsung.xml. Прежде всего нужно указать тестируемый сервер, следующим образом:

<servers>
   <server host="example.com" port="80" type="tcp"></server>
</servers>

Далее адрес эмулируемого клиента, для масштабных тестов рекомендуется менять порог maxusers:

<clients>
     <client host="localhost" use_controller_vm="true" maxusers="7000"/>
</clients>

И самое интересное, желаемая нагрузка. Tsung симулирует посещения юзеров. Следующий пример иллюстрирует 2 фазы. Первая длится 5 минут и каждую секунду сайт посещает 10 новых пользователей, итого 5 минут x 10 юзеров/сек = 3000 юзеров. Вторая фаза еще более повышает нагрузку и длится 10 минут, каждую секунду приходит 25 юзеров, в сумме 15 000 юзеров.

<load>
 <arrivalphase phase="1" duration="5" unit="minute">
	<users arrivalrate="10" unit="second"/>
 </arrivalphase>
 <arrivalphase phase="2" duration="10" unit="minute">
	<users arrivalrate="25" unit="second"/>
 </arrivalphase>
</load>

Вместо arrivalrate можно также использовать
<users interarrival="2" unit="second"/>
в этом случае юзер будет приходить каждые 2 секунды.

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

 <sessions>
  <session name="rec20111101-1537" probability="100" type="ts_http">
	<request><http url="/test/test.html" version="1.1" method="GET"/></request>
	<request><http url="/css/global_mainPage.css" version="1.1" method="GET"/></request>
	...
	<thinktime random="true" value="15"/>
  </session>
  <session>
   ....
</session>
 <sessions>

Автоматическая генерация сессии


Сессию можно создавать вручную, но есть более простой способ — использовать прокси tsung'а для записи ваших действий на сайте. Для этого нужно только прописать в настройках вашего браузера ip сервера где установлен tsung и порт 8090. Далее необходимо выполнить команду tsung-recorder start побродить по сайту, сэмулировать поведение обычного посетителя. Чтобы остановить запись tsung-recorder stop. После этого сгенерированная последовательность появится в ~/.tsung/tsung_recorderyyyymmdd-HH:MM.xml. Далее неоходимо просто скопировать эту сессию в основной файл tsung.xml.

Запуск


Вот наконец когда проделаны все подготовительные действия можно и запустить наш тест. Для этого необходимо ввести команду tsung start , для остановки соответственно tsung stop. Tsung будет записывать log в каталог ~/.tsung/log/yyyymmdd-HH:MM. Очень важный момент при масштабных тестах, перед запуском установить значение ulimit больше стандартного в моем случае 1024, ulimit -n 100000. Для просмотра статуса о количестве юзеров на сайте, можно использовать команду tsung status. Сгенерированный лог помещается в каталог .tsung/log/yyyymmdd-HH:MM.

Генерация отчета и диаграмм


Для генерации отчетов используется скрипт на perl идущий вместе с программой — tsung_stats.pl. Скрипт необходимо запускать из директории с логом, командой perl tsung_stats.pl. После чего сгенерируется замечательный html отчет и диаграммы.

Tsung предоставляет статистику:
  • Производительность: время ответа, время присоединения, транзакции, запросы в секунду
  • Ошибки: статистика по возвращенным ошибкам
  • Поведение сервера: График занятости CPU и памяти, сети. SNMP

Вот пример одной из диаграмм (количество юзеров на сайте, и количество сгенерированных юзеров):


Больше диаграмм на сайте разработчиков

Источники:


Руководство Tsung
+79
10520
357
isergeymd 5,5

комментарии (58)

0
WebResult, #
<request><http url="/test/test.html" version="1.1" method="GET"/></request>

я так понимаю, можно использовать и POST запросы. а как передавать данные в POST?
+3
ha2bj, #
manual

<request>
       <http url="/bla" method="POST" version="1.1" contents="bla=blu&name=glop">
</request>
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
+2
ixolit, #
От MS есть нечно подобное под винду: wcat
–1
AlexRussian, #
Ага, у нас на проекте используется wcat. Основная причина почему мы его используем — это его возможность генерации результатов в формате xml и наличие xsl файла в комплекте, который позволяет просматривать html отчет (хотя и без графиков) в аккуратном виде. Html — потому что потом это было легко интегрировать в автоматическую рассылку. Подобной возможности не было найдено в JMeter. Насколько я знаю JMeter так же не умеет захватывать счетчики производительности на удаленном сервере (поправьте если я ошибаюсь).

Как обстоят дела с этим у Tsung?

Из минусов wcat — отсутствие возможности наращивать количество пользователей во время теста.
+1
isergeymd, #
Tsung предоставляет и html отчеты, я обновил пост по отчетам. У Tsung есть собственный измеритель произодительности, на счет захвата счетчика производительности на удаленном сервере в документации не нашел ничего.
+1
Optik, #
Есть плагины для jmeter на гуглокоде, там насколько знаю есть возможность хватать метрики с нагружаемых серваков. Хотя никогда по этому поводу не заморачивался, и использовал метрики, записанные осью или сторонним софтом.
–2
Optik, #
Расширяемость продукта есть? Работа под другой осью? Расписания? Генерация данных и анализ ответов?
0
isergeymd, #
ось только *nix (Linux, BSD, MacosX, Solaris), расписаний и генераций данных не замечал, ответы можно из ответа посмотреть по статистике ошибок, что вы подразумеваете под расширяемостью?
0
isergeymd, #
^отчета простите
0
Optik, #
Расширяемость это значит к примеру написать свой протокол, или сложную реализацию сценария. В jmeter к примеру есть для этого специальный интерфейс. Пока из описания продукта вижу, что он написан на функциональном языке что в теории даст большую производительность. Все остальное, что могут предоставить другие инструменты, либо не превосходит либо совсем отсутствует (отсутствие генерации разных запросов это гигантский минус). Да и высокая производительность плюс с натягом. Это разве что тестировать со слабой машины продукты, предназначенные для высокой нагрузки (сотни тысяч запросов в час). В общем, софтина получается применима далеко не везде и не всегда.
Ну и еще вопрос, оно сохраняет данные по запросам (цифры хотя б) в файлы или только графики само строит?
0
isergeymd, #
На счет расширяемости я наверно не так осведомлен, наверно в теории вы можете написать протокол на erlange. На счет генерации разных запросов это либо вручную прописывать либо через прокси, на лету я как понял нельзя модифицировать запросы, а зачем вам в принципе это потребовалась?
Да, данные по запросам есть в логе.
0
Optik, #
Ну если он еще с открытыми исходниками, то конечно в теории можно, вопрос насколько это просто)
Про генерацию на лету, самый простой пример. Как вы без неё будете логинить юзера? Вы же не подсунете ему идентификатор сессии в запрос.
0
isergeymd, #
обычный post запрос, и еще там есть таки возможность создавать данные динамически исходя из предыдущих запросов, с использованием
<dyn_variable>
0
DmZ, #
Какие преимущества перед тем же JMeter?
0
isergeymd, #
я особо не изучал JMeter, но мне кажется там есть определённые ограничения на количество одновременных юзеров, и еще т.к. сделано на java соответственно ресурсов будет кушать больше
+1
Optik, #
У Jmeter ограничения только ресурсы машины, но даже несмотря на несколько большие требования (с тем же LoadRunner в сравнении он вообще дистрофик) проблем с этим не было ни разу даже при тестировании высоконагруженных промышленных систем. В крайнем случае можно использовать распределенный режим нагрузки.
0
isergeymd, #
Ну к примеру для 1млн юзеров, это же какой сервер нужен будет для запуска Jmeter? Для скольки юзеров у вас получалось запускать Jmeter?
+1
Optik, #
Миллион юзеров нужен почти никогда. Софт каждого виртуального юзера представляет одним потоком. Когда он выполнил свое действие, то поток не убивается, а используется повторно. Убивать сам поток смысла не имеет раз, а затраты системы на создание нового довольно существенны (вне зависимости от языка) — это два. Поэтому разговор при нагрузке идет не о миллионах пользователей, а о количестве запросов в единицу времени. Могу на личном опыте привести пример. SFTP протокол (шифрование, это дополнительная нагрузка на систему), файлы генерируются на лету и имеют размер около 5кб. С рабочего ноута нагрузку можно было создавать 200-250 запросов в секунду. Обычный хттп уходит за тысячу, максимум не смотрел, ибо и тысячи не надо было.
+1
esl, #
>а затраты системы на создание нового довольно существенны (вне зависимости от языка) — это два.

фраза ошибочна, ОСОБЕННО в контексте ERLANG ;)

>Обычный хттп уходит за тысячу, максимум не смотрел, ибо и тысячи не надо было.

вам не надо было, а если бы и надо — то не смогли бы решить, инструмент не позволит.

tsung — позволит, но вам похоже это не светит (ибо у вас уже все хорошо, и больше не надо, ну никому и ни при каких условиях)
0
Optik, #
фраза ошибочна, ОСОБЕННО в контексте ERLANG ;)
Не путайте операцию выполняемую операционной системой и расчеты, может для второго функциональные языки и прекрасны, но первое не в их власти. Каждый поток требует выделения ресурсов, и хотел бы я посмотреть как 1млн потоков будет жить одновременно на банальной рабочей тачке.

вам не надо было, а если бы и надо — то не смогли бы решить, инструмент не позволит.

tsung — позволит, но вам похоже это не светит (ибо у вас уже все хорошо, и больше не надо, ну никому и ни при каких условиях)
Спрячьте свой фанатизм, и не приписывайте мне своих домыслов. Там не написано что не смог бы, вопрос в том сколько надо. 1000000 юзеров это не показатель. За какое время этот миллион набегает?
+1
rustler2000, #
www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1

Если правильно помню то 36гигов на 1миллион комет клиентов
0
VolCh, #
Может я что-то упустил, но разве сабж создает поток на каждый запрос к удаленному серверу?
0
Optik, #
У меня сложилось такое ощущение из слов рассказывающих. Они говорят про миллион юзеров, говорят что никто так не сможет и не говорят за какое время. Надо будет спросить на работе можно ли выложить презенташку для стажеров по нагрузке, а то лень самому рисовать картинки.
+1
maxcom, #
Там на каждого пользователя заводится процесс виртульной машины, они не соответствуют тредам ОС. Чисто внешне (если смотреть strace) это выглядит как программа написанная с использованием мультиплексного ввода-вывода (select/poll/epoll и т.п., что именно зависит от ОС)
0
VolCh, #
>Миллион юзеров нужен почти никогда

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

0
VolCh, #
Ну хоть бы сказали за что минус…
+1
VolCh, #
А все юзеры одинаковые? Нельзя, сажем, для пост-запросов брать логины/пароли из файлика?
+2
esl, #
можно,
из файлов, из базы — это то что есть готовое
0
VolCh, #
Зер гут :) Тогда интересно, а то насколько быстро nginx будет отдавать статический контент мало интересно, когда подавляющее большинство строго персонализировано.
0
isergeymd, #
можно делать под разными ip читай тут lists.process-one.net/pipermail/tsung-users/2008-February/000759.html, думаю нет
+1
Optik, #
Разный IP нужен крайне редко при нагрузке, по словам коллег еще ни разу не пришлось пользоваться в работе. А вот использовать разные данные в запросе надо часто.
0
isergeymd, #
я ошибался оказывается есть поддержка считывания из файла,
 <option name="file_server"  value="/tmp/userlist.csv"></option>
0
esl, #
разные IP нужны при наличии балансировки нагрузки
просто у ВАС нет такой необходимости, видимо маленькая система.
пом никсами tsung позволит использовать сотни IP на одной машине.
+1
Optik, #
Я вас растрою наверно но спуфинг айпишников есть во многих инструментах (и о боже, даже под виндой).
0
DmZ, #
Разные ip полезны когда проверяешь различные лоадбалансеры и jmeter прекрасно справляется благодаря нескольким клиентам. А вот отсутствие загрузки кастомных данных… Тут и httperf справится :-)
0
esl, #
а тут на ОДНОМ клиенте :)
0
DmZ, #
Просто не было необходимости делать это на одном хосте — в jmeter можно наконфигурить все ip адреса которые есть на хосте, правда (сходив по ссылке), наверно менее элегантно чем в tsung.

Ушел изучать tsung %)
+2
esl, #
понятно что это нужно только при ОЧЕНЬ высоких нагрузках
для таких случаев и нужно много IP и очень много клиентов
в общем всего много :)
и кластер для tsung делается ОЧЕНЬ просто
но это опять про очень высокие нагрузки

и да, гуя нету совсем
и надо уметь читать логи
и надо понимать как работает HTTP
и надо понимать как ТОЧНО работает ваше приложение
0
DmZ, #
Это все не проблема, понравился подход tsung к мониторингу что в одном месте собрана статистика с сервера (cщpu, mem, etc.) и привязано к результатам нагрузки.
0
DmZ, #
А так как весь парсинг логов/результатов отдан на откуп пользователю — можно удобно сделать историю нагрузок
0
IgorMats, #
Так, а как график то генерировать? Почему-то в папке с логами никаких Perl скриптов нет.
+1
isergeymd, #
у меня скрип лежал кажется в /usr/local/lib/tsung/bin/tsung_stats.pl, то есть куда установился
0
IgorMats, #
Да, нашел. Спасибо.
0
grobik, #
jmeter позволяет парсить ответ сервера, выдергивать оттуда нужные данные и подставлять в следующий запрос (часто нужно для ajax запросов). Умеет ли делать это цунг?
0
isergeymd, #
да можно, с использованием Regexp либо XPath tsung.erlang-projects.org/user_manual.html#htoc65
0
seriyPS, #
Видно, что штука отличная. Но ему бы какой-нибудь DSL для конфигов не помешал. XML как-то не очень смотрится.
0
esl, #
что-то есть rtsung
+1
hg_04, #
я вот смотрю вы прописываете статику

а он сам может подтягивать всю статику со страниы? без описания
0
isergeymd, #
ммм боюсь что нет, иначе зачем тогда нужны эти манипуляции с прокси
+6
Sov1et, #
ЗАЧЕМ?!?! Скажите зачем?!?! Делать make install и тд. Когда вот тут есть пакеты под разные системы!
tsung.erlang-projects.org/dist/
0
anycolor, #
а даже если и делать, то не через make install, а через checkinstall
0
isergeymd, #
ну я предоставил универсальный вариант:), если честно я не заметил их
0
maxcom, #
tsung интересная штука, но его графики/цифры сильно зависят от того как настроена сессия пользователя. В итоге довольно важно качество составления теста и правильная интерпретация результатов тестирования, это еще отдельная задачу.

Более простые инструменты (вроде Apache Benchmark) имхо дают более простую и понятную оценку.
0
CheatEx, #
Он же долбит один и тот же запрос в цикле из n-потоков. Или я что-то упускаю?
0
CheatEx, #
А не можете поподробнее рассказать про симуляцию разной статистики использования. По xml видно, что как-то вероятность можно задать поведение, но хотелось бы big picture.

Можно ли брать адреса запросов или какие-то параметры из файлов/БД? Как их ожно ассоциировать с сессиями?

В JMeter основная проблема большая костыльность симуляции более-менее правдоподобной нагрузки.
0
isergeymd, #
Это тема отдельной статьи, правда не знаю когда, сейчас довольно много чего нужно изучать…

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