Пользователь
0,0
рейтинг
22 июля 2009 в 15:40

Разработка → Siege — утилита для нагрузочного тестирования веб-серверов перевод

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

Параметры запуска
Формат запуска Siege следующий: «siege опции». Программа может принимать следующие параметры:

' -V '
' –version'
Выводит на экран текущую версию.

' -h '
' –help'
Выводит справку.

' -C '
' –config'
Показывает текущую конфигурацию. Siege считывает настройки и выводит их содержимое. Вы можете их менять редактируя файл $HOME/.siegerc. Если такого файла у Вас нет, следует запустить утилиту siege.config, которая его сгенерирует

' -v '
' –verbose '
Подробный вывод информации. Если эта опция включена Siege будет выводить на экран детальную информацию обо всех обращениях к серверу. Она включает в себя тип HTTP-протокола, код ответа и адрес обращения. Пример:

HTTP/1.1 200 OK: /cgi-bin/whoohoo.cgi?first=Homer&last=simpson

Эта опция особенно полезна в случае регрессионного тестирования или имитации Интернета, когда программа обращается в широкому кругу адресов.

' -g URL '
' –get URL'
Совершает обращение к указанной ссылке. Получает заголовки с сервера и выводит их на экран. Отличный инструмент для точечного тестирования.

' -c NUM '
' –concurrent=NUM '
Количество имитируемых пользователей. Опция позволяет производить тестирование веб-сервера с количеством одновременных пользователей указанных в NUM. Фактически это число ограничивается лишь ресурсами компьютера, но в на практике для хорошего результата требуется имитировать всего пару сотен пользовательских сессий. Помните что при любой конфигурации Вы всё равно не сымитируйте поведение настоящих людей. Хотя бы потому что они задерживаются на каждой странице, читая информацию, а не перебирают ссылки одну за другой.

' -i '
' –internet '
Эта опция используется с конфигурационным файлом содержащим множество ссылок. При её включении Siege случайно выбирает адреса обращений и производит к ним запросы. В реальности Вы не можете сказать пользователям на какие страницы и в какой последовательности они должны заходить. Они будут делать это всегда по разному. Режим имитации Интернета пытается эмулировать такое поведение. Обратите внимание на то что в процессе тестирования к некоторым адресам из файла может не произойти обращений вообще ведь они выбираются случайно.

' -t NUMm'
' –time=NUMm '
Время, за которое должно пройти тестирование. Указывается в формате «NUMm», где NUM это количество единиц времени, а «m» это модификатор S, M, или H для секунд, минут и часов соответственно. Например, для того чтоб запустить тестирование на час Вы можете воспользоваться следующими комбинациями: -t3600S, -t60M, -t1H. Модификатор не чувствителен к регистру, но между ним и числом не должно быть пробелов.

' -f FILE '
' –file=FILE '
Конфигурационный файл содержащий ссылки (SIEGE_HOME/etc/urls.txt). Вы можете использовать эту опцию для того чтоб указывать другой путь к нему. Например:

siege –file=serverb.txt

' – l '
' –log '
Эта опция указывает Siege что она должна записывать всю информацию в лог-файл SIEGE_HOME/var/siege.log. При каждом новом тестировании файл будет дописан.

' – m MESSAGE '
' –mark=MESSAGE '
Эта опция позволяет указать выражение которым будут разделяться записи о разных тестированиях в лог-файле. Вместе с ней не обязательно использовать опцию -l, т.к. она будет включена автоматически. Если выражение в MESSAGE содержит пробелы не забудьте поместить его в кавычки.

' -d NUM '
' –delay=NUM '
Эта опция указывает задержку между обращениями имитируемых пользователей к серверу. Время задержки вычисляется от единицы до введённого числа. При проведении тестирования на ресурсоёмких участках приложения желательно ставить задержку равную секунде ( -d1 ). По умолчанию задержка происходит от 1 секунды до 3. Эта опция позволяет как бы накрывать сервер волнами запросов.

Конфигурационный файл
Начиная с версии 2.00 Siege поддерживает конфигурационные файлы в которых Вы можете хранить часто-используемые команды. Это может помочь при большом количестве тестирований с почти одними и теми же настройками. Данный файл называется .seigerc и располагается в домашней директории пользователя установившего Siege. Если этого файла там нет (например устанавливали программу не Вы) то можно воспользоваться утилитой siege.config для его создания. Внутри файла находятся различные директивы с комментариями к ним. Редактирование Вы можете проводить с использованием любого текстового редактора.

Формат передаваемых URL
Siege понимает следующий формат ссылок:

[протокол://] [сервер.домен.xxx] [: порт] [/диерктория/файл]

Поддерживаются адреса только с протоколами HTTP и HTTPS. Минимум что Вы должны указать – имя сервера. Если Вы находитесь внутри какого-то домена и тестируете сервер с именем shemp, и он прописан в Вашем файле хостов или на местном DNS, тогда команда
“siege -u shemp” произведёт обращение к адресу shemp.домен.net/index.shtml. Если Вы хотите чтоб Siege работал с https-сервером то нужно указать дополнительно ещё и протокол. Таким образом команда “siege -u shemp” заставит программу обращаться по адресу shemp.yourdomain.net/index.shtml.

Файл с сылками
Перед тем как запустить регрессионный тест или режим имитации интернета Вам нужно передать программе список проверяемых адресов. Для этого поместите их в файл SIEGE_HOME/etc/urls.txt. В нём адреса должны располагаться по одному на строку:

homer.whoohoo.com/howto.jsp
homer.whoohoo.com/index.jsp
homer.whoohoo.com/cgi-bin/hello.pl?first=bart&last=simpson

и т.д.

Siege-2.06 и более поздние версии поддерживают наличие POST и GET директив. GET директива используется по умолчанию и указывать её не обязательно. А вот для POST-запроса директиву следует указать. Пример:

homer.whoohoo.com/cgi-bin/hello.pl POST name=homer
homer.whoohoo.com/haha.jsp POST word=doh!&scope=ALL


Когда Вы запускаете программу без опции [ -u URL | --url=URL ], она берёт адреса именно из этого файла. В нормальном режиме Siege начинает с начала файла и постепенно обращается ко всем адресам. Если Вы выбрали режим имитации Интернета [ -i | --internet ], то обращения к адресам происходят случайным образом. Вы можете указать другой путь к файлу с ссылками через опцию [ -f FILE | --file=FILE ].

Переменные
Начиная с релиза версии 2.57, Siege поддерживает объявление переменных в файле .siegerc и в файлах со ссылками ( urls.txt ). Синтаксис объявления переменных Siege похож на синтаксис UNIX shell. Они объявляются по одной на строку в формате “varname=value”
Название переменной помещается внутрь конструкции $() или ${}. Вы можете использовать их например для быстрого переключения между двумя протоколами проверяемых ссылок:

PROT=https://
$(PROT)eos.joedog.org/siege/index.php
$(PROT)eos.joedog.org/wacky/index.php
$(PROT)eos.joedog.org/scout/index.php
$(PROT)eos.joedog.org/libping/index.php
$(PROT)eos.joedog.org/gunner/index.php


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

Log File
Когда Siege запускается с включенной опцией логирования [-l/--log], программа заносит всю выводимую информацию в PREFIX/var/siege.log, где PREFIX – установочная директория Siege ( смотрите файл INSTALL ). В лог-файл пишется всё что выводится программой на экран в стандартном режиме. Информация при записи разделяется запятыми для быстрого импорта в другие форматы.
Для разделения результатов разных проверок имеется опция -m “текст”/–mark=”текст”. Она помещает указанное сообщение в лог-файл перед началом сканирования чтоб Вы смогли быстро найти его результат. Например, если Вы тестируете ссылки по протоколам http и https, Вы можете оставлять в логах пометки типа “start HTTPS testing”. Если Вы используйте опцию -m/–mark то параметр -l/–log использовать не обязательно.

Статистика исследования
Статистика, выдаваемая программой, включает в себя общее время тестирования, общее количество переданных данных ( включая заголовки ), среднее время ответа сервера, его пропускную способность и количество обращений на которые сервер ответил кодом 200. Сам отчёт формируется скриптом Линкольна Штейна (Lincoln Stein) torture.pl. Вот пример отчёта Siege:

Ben: $ siege -u shemp.whoohoo.com/Admin.jsp -d1 -r10 -c25
..Siege 2.65 2006/05/11 23:42:16
..Preparing 25 concurrent users for battle.
The server is now under siege…done
Transactions: 250 hits
Elapsed time: 14.67 secs
Data transferred: 448000 bytes
Response time: 0.43 secs
Transaction rate: 17.04 trans/sec
Throughput: 30538.51 bytes/sec
Concurrency: 7.38
Status code 200: 250
Successful transactions: 250
Failed transactions: 0


Здесь:
Transactions – количество обращений к серверу. В примере это число высчитывается из 25 пользователей [ -c25 ] запустивших по 10 обращений [ -r10 ], что в общей сумме составляет 250.
Elapsed time – общая продолжительность тестирования. Она высчитывается начиная с первого обращения к серверу и кончая получением ответа на последний запрос. В примере тест занял 14.67 секунд.
Data transferred – суммарное количество данных переданное всеми имитируемыми пользователями. Оно включает в себя как тела запросов, так и их заголовки.
Response time – среднее время за которое сервер успел ответить клиенту.
Transaction rate – среднее число обращений которые сервер успел обработать за секунду. Оно получается путём деления общего числа запросов на затраченное время.
Throughput – среднее число данных передаваемых ежесекундно от сервера к пользователям.
Concurrency – количество одновременных подключений при которых сервер отвечает без задержек.
Successful transactions – количество запросов на которые сервер ответил кодом меньше 400.

Платформы
Мульти-потоковый Siege был собран и успешно оттестирован на следующих платформах:

* AIX( powerpc-ibm-aix4.2.1.0 ). Siege скомпилирован и успешно протестирован с использованием компилятора “IBM C for AIX” версии 5.
* GNU/Linux ( i[56]86-pc-linux-gnu ). Siege был разработан на SuSE GNU/Linux с gcc.
* HP-UX ( hppa2.0w-hp-hpux11.00 ) Siege был скомпилирован на этой платформе с использованием “HP ANSI C compiler” и gcc.
* Solaris ( sparc-sun-solaris2.[678] ) Siege обожает эту платформу. Она была нормально скомпилирована на ней с использованием gcc.
* Microsoft Windows ( pc-i686-cygwin ) Siege была портирована на Cygwin Funkman`ом. На нём нормально работают все версии Siege после 1.5.

Авторы
Jeffrey Fulmer – Спроектировал и реализовал Siege будучи в должности веб-мастера в компании “Armstrong World Industries”.
Информация о лицензии
Для получения полной информации о лицензии посмотрите файл COPYING. Авторские права полностью принадлежат Джеффри Фалмеру (Jeffrey Fulmer). Каждому разрешается производить и распространять копии этого документа без каких-либо изменений. Разрешено изменение этого документа и распространение его изменённых версий только в случае указания изменённых мест.

Автор перевода — Kuzya
Перевод: Джеффри Фалмер (Jeffrey Fulmer)
Ян @kalpsik
карма
24,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (67)

  • +7
    Реально полезная вещь! Давно искал что-то подобное. Спасибо!
    • +1
      рад, что помог!
    • +2
      Есть ещё Tsung
      • 0
        Благодарю. Тоже посмотрю. А то уже сам собирался писать что-то такое на php, чтобы движок свой на нагрузку протестировать хоть как-то.
      • +5
        а для апача еще есть стандартный ab
    • +2
      Посмотрите ещё на Jmeter, может тоже полезно будет.
  • +2
    А можно ли симитировать движение пользователя по сайту, использующему сессии?
    Т.е. первый запрос — это запрос авторизации, а дальше запрашиваются какие-то страницы.
    При этом «пользователи» разные.
    • 0
      к сожалению, на данный момент нет. по крайней мере на сайте автора нет упоминаний про авторизацию.
      • +2
        на главной странице сайта в первом абзаце:
        Siege supports basic authentication, cookies, HTTP and HTTPS protocols.
        :)
        • –1
          прошу прощения — не доглядел=) сам только начинаю разбираться.
          • +2
            Может быть, Вы, когда разберетесь, выложите несколько полностью расписанных сценариев использования?
            • +1
              обязательно выложу!
              • 0
                Буду ждать:)
                Удачи!
        • 0
          Что ж, спасибо:)
          Значит, можно брать на заметку.
        • 0
          Я бы не назвал поддержку cookies полноценной, ведь нельзя установить куку для имитации зарегистрированного юзера.
          • 0
            Беру свои слова назад. Куки прекрасно передаются с помощью -H:

            $ siege -H «Cookie: name=val; name2=val2; ...»
    • 0
      В Selenium есть реализация сценариев.
      • 0
        Selenium — система для автоматического функционального тестирования. Для стресс-тестирования вряд ли подойдет
        • 0
          Есть возможность записать сценарий в Selenium, а потом экспортировать его в jmeter.
    • 0
      Советую попробовать Apache Jmeter — и для начинающих очень удобен (есть gui для разработки тест-планов) и для серьезных тест-задач тоже очень хорош. Поддерживает распределенное тестирование, http сессии и аутентификацию, сложные сценарии, графические отчеты, сохранение результатов, пре/пост-процессоры контента и еще кучу других полезных фич.
      Единственный серьезный минус — жрет много памяти (по сравнению с тем же siege).
      здесь краткий туториал на русском.
  • +4
    Пока из бесплатного лучше Apache JMeter ничего не видел. Нужно посмотреть этого зверя поближе
    • +1
      JMeter не умеет генерировать большие нагрузки (>5 KRPS) с одного хоста.
      • 0
        А во что он «упирается»? В смысле почему не умеет? Искусственное ограничение, или тредов в операционке не хватает?
        • 0
          В Яву он упирается. И в архитектуру свою. За гибкость надо платить.
          • 0
            А если на машинке 8 процессоров и 16 гигов памяти? Сможет преодолеть это ограничение? Если что, я могу проверить ;)
            • 0
              Для StateFull тестов наврядли. Но попробуйте. Эффективнее кластеризовать.
      • 0
        Jmeter вообще странный — то запущенный тест не останавливается иначе как по kill -9, то результаты первого и второго прогонов отличаются в 2 раза, то собраная статистика не стирается иначе как перезапуском. И BeanShell — вообще чудо какая штука.

        Вобщем, ура ещё одному бенчмарку вебсерверов, и большое спасибо за использование Си =)
    • 0
      Да. Отличная штука, очень удобна в использовании.
  • 0
    а есть инструменты для записи сценариев? или тесты нужно писать вручную?
    OpenSTA позволяет записывать сессии и потом их воспроизводить, еще вроде WAPT такое позволяет и еще несколько тулзеней названия которых сейчас уже и не вспомнить (последний раз пользовался этим добром лет 5 назад, а то и больше).

    в общем хотелось бы понять в чем перелесть Siege. чем она лучше или хотя бы не хуже уже существующих инструментов?
    • +1
      OpenSTA позволяет записывать сессии и потом их воспроизводить, еще вроде WAPT такое позволяет и еще несколько тулзеней названия которых сейчас уже и не вспомнить

      JMeter умеет работать в качестве прокси и на основе запросов записывать план тестирования.
    • 0
      Ну siege — тоже «уже существующий инструмент», и совсем даже не новый) Как мне показалось — эдакая замена для ab, только понавороченней.
  • +4
    А мне интересно — программа обращается к указанным адресам, загружая только саму HTML-страницу (или файл, ясное дело) или производит анализ и загружает ещё и всё, что есть на этой странице (картинки, скрипты, внешние CSS и т.п.)?

    По-моему не слишком получается объективное тестирование, если программа долбится и скачивает только сами HTML-файлы, ведь любой высоконагруженный проект разделяет нагрузку между серверами (вроде Apache + nginx + кэш сверху), и хотелось бы оценивать всю систему в целом. Кто-нибудь знает что-нибудь подобное? :)
    • 0
      можно дописать подгрузку стилей и т.п.:)
      по-хорошему должно быть несложно
    • +1
      Посмотрите на Jmeter, там есть опции загрузки медиа (можно включить, можно выключить).
      • 0
        Спасибо, посмотрим :)
  • 0
    Именно с помощью этой утилиты два уже «тестируют» мои серверы какие то школьники. Так что использовать можно и для не совсем благих намерений.
  • +1
    Переносной «хабраэффект»? Спасибо, проверюсь!
  • 0
    Siege? Heil!
  • 0
    "..Preparing 25 concurrent users for battle."
    Из серии «Программисты шутят» :)
    ^___^
  • 0
    ApacheBench + Перловый модуль HTTPD::Bench::ApacheBench?
  • +1
    Ачат жив… у кузи всегда интересные материалы
    • 0
      только вот последнее время в дауне очень часто=( а так ресурс хороший, давно на нем.
  • 0
    Чем он лучше ab?
    • –2
      А если нужно тестить IIS?
      • +2
        Да хоть webmin, без разницы. ab — это http-клиент, и ему без разницы, кто ему на запросы отвечать будет.
    • 0
      ab вроде бы просто тупой бенчмарк — натравили его куда-нибудь, и он запрашивает страницу с макс. возможной частотой. Поправьте, если нет, могу тут ошибаться, конечно, но на превый взгляд — так.

      А siege умеет имитировать (в какой-то мере) действия пользователей. Например, N пользователей делают запросы (как GET, так и POST) к разным страницам, причем каждый пользователь — через случайный интервал времени (например, от 1 до 10с).
      • 0
        Мне не понятен сам смысл этой задумы. А что если в один прекрасный момент пользователи всей толпой ударят по одному узкому, тормозному месту, вместо ваших рандомных манипуляций с этой программе.
        Я думаю разработчик тестируемого веб-проекта лучше этой программы знает, какие запросы будут самыми тяжёлыми. Так зачем включать в тест эту имитацию? Которая, кстати, только добавит воды в тест. И отожрёт процессорное время если тестирование будет происходить на той же машине…
        • 0
          1. Узкое место может быть не так, где ожидалось.
          2. Возникнуть оно может из-за того что все долбятся не в одну страницу, а в разные. Одна страница может закешироваться, а пачка страниц может в кеш не влезть и вылезет проблема.
          • 0
            Согласен. Могут быть проблемы с какими-нибудь блокировками БД… Файлов… И прочего…
            Хм… Полезный инструментарий 8)))
            • 0
              Был бы еще полезнее, если бы работал как спайдер. В конфиге задавались правила, куда можно ходить, а куда нельзя (например, за пределы домена) и спайдер бы сам по ссылкам ходит, которые он видел на странице, авторизировался в формах, используя пул паролей и логинов итд. Вот тогда, исключая места в которые можно попасть только через JS или постинга формы с, например, капчей, было бы более-менее приближенное к реальности тестирование.
              Ведь на тех паре десятков url что будут внесены в конфиг, проблемы наверняка не возникнет, в кеш все влезет.
  • 0
    стоит однако заметиьт что siege относительно ab2 жутко (!) прожорливый. Например, если натравить на helloworld апача — то 90% cpu на той же машине сожрёт сам siege.

    + он у меня показал чудеса нестабильности, опять же относительно ab2.
  • +1
    Есть ли какие-нибудь преимущества, помимо компактности, у Siege по сравнению с микрософтовской
    Web Application Stress (WAS) Tool (см. support.microsoft.com/kb/313559)?
    • 0
      думаю, что одно из них — кроссплатформенность
  • 0
    Удивительно хорошая утилитка. Наконец-то я проверил максимальную нагрузку на свою самопальную вики. Оказалось, что на 100 юзерах 18% запросов просто утеряется по таймауту… жуть. А всё из-за перла, на движке которого вики и сидит… Может питон лучше будет?
    • +1
      Пересмотреть алгоритмы будет лучше… Не исключено что узкое место в базе, например.
    • 0
      А всё из-за перла, на движке которого вики и сидит…

      Жесть… Судя по всему — вы хоть на чистом СИ пишите, толку не будет.
      Некоторые вунь на ПХП высоконагруженные сайты пишут. И ни чего.
      Плохому танцору...(с)
      • –2
        Можно и на си написать — лишь бы за это заплатили =)
        А если серьёзно, простая проверка нагрузки cpu top'ом показала, что при 10 пользователях страница генерируется перловым скриптом аж 2.5 секунды, при этом жрёт это радость 25-30% cpu, на 2х ядерном 2х процессорном сервере. Чего уж там скрывать — основа сайта twiki движок. Создаётся он как опен-сорс проэкт. И ожидать там всерх быстрой производительности я и не собирался. Самому писать двигло для сайта — тоже как-то… нету столько свободного времяни.
        А про плохого танцора, уважаемый, вы себе сайт сами целиком писали?
        • 0
          Себе — нет.
          Сапожник без сапог…
          А вот заказчикам — да. Фрилансом, знаете ли, подрабатываю. Замечу — писал не домашние странички Васей Пупкиных…

          что при 10 пользователях страница генерируется перловым скриптом аж 2.5 секунды, при этом жрёт это радость 25-30%
          Поменяйте профессию.
          • +2
            Я био-физик… буду менять на кондитера, но не скоро.
            • +1
              В таком случае — снимаю шляпу.
              НО. Пожалуйста. Не имея навыков — не гоните на язык программирования. Он здесь не при чём.
  • 0
    А ab отменили?
  • +1
    Надеюсь, что данный материал будет кому-нибудь полезен.
    Не скромничайте!.. :)
  • 0
    Спасибо за статью, только пришлось гуглить чтобы скачать. Кому нужно выкладываю ссылку для скачивания Siege
    • 0
      На сколько я понял правильная ссылка www.joedog.org/siege-home/.
      Так же можно установить в ubuntu через apt-get.
  • 0
    Спасибо за перевод мана :).
    Отметьте, пожалуйста, особо, что в определении var=value пробелы вокруг '=' недопустимы, а то оригинальный ман вводит в заблуждение.
  • 0
    Спасибо за статью.
    Вот тут
    >>Concurrency – количество одновременных подключений при которых сервер отвечает без задержек.
    не точный перевод
    Concurrency is average number of simultaneous connections, a number which rises as server performance decreases.
    примерно так:
    Concurrency – среднее число одновременных подключений, которое увеличивается с падением производительности сервера.
  • 0
    Transactions: 147993 hits
    Availability: 99.78 %
    Elapsed time: 599.92 secs
    Data transferred: 1870.78 MB
    Response time: 0.98 secs
    Transaction rate: 246.69 trans/sec
    Throughput: 3.12 MB/sec
    Concurrency: 240.89
    Successful transactions: 81039
    Failed transactions: 332
    Longest transaction: 29.66
    Shortest transaction: 0.01

    Вот не пойму 81039+332 не равно 147993, где еще часть запросов?

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