Инструменты для нагрузочного тестирования HTTP-серверов?
Мне приходилось загружать тестовые HTTP-серверы/веб-приложения несколько раз, и каждый раз я был поражен качеством инструментов, которые мне удалось найти.
Итак, когда вы тестируете HTTP-сервер, какие инструменты вы используете? И что я, скорее всего, сделаю неправильно, когда в следующий раз мне придется это делать?
JMeter бесплатно.
Mercury Interactive Load Runner - супер хороший и супер дорогой.
Я чувствую себя необычайно квалифицированным, чтобы ответить на этот вопрос, поскольку моей нынешней компании необходимо смоделировать 25 000 одновременных подключений к нашим веб-серверам (мы размещаем онлайн-рекламу).
Для нагрузочного тестирования чрезвычайно большого объема, Httperf это путь. Это бесплатно и, по нашему опыту, оно может имитировать больше одновременных соединений, чем JMeter или STA на одном оборудовании.
Правка:
Если вам интересно, мы моделируем 3500 запросов в секунду на маломощном, недорогом, ультра-малом форм-факторе Optiplex 330. Эти маленькие коробочки стоят всего $ 280, и у нас есть куча из них, подключенных к работе. Httperf по требованию. Для сравнения, JMeter мог выдавать только 800-900 запросов в секунду на этом оборудовании.
Если вы просто хотите загрузить нагрузку по одному URL-адресу за раз на веб-сервере, скачайте Apache AB. Поставляется с сервером Apache HTTP.
Простая команда
ab -n 10000 -c 10 http://serverfault.com/questions/2107/tools-for-load-testing-http-servers
будет выполнять 10000 запросов с одновременным доступом 10 пользователей.
Если вы хотите записать сеансы просмотра, тогда идите вверх и примите ответ jmeter. Jmeter поразителен и может масштабироваться на многих тестовых машинах, которые могут бросить огромную нагрузку.
Существует Tsung , инструмент на основе Erlang.
Также есть очень длинный список инструментов на http://www.softwareqatest.com/qatweb1.html#LOAD
Для быстрого теста вы можете использовать последовательности завитков и наборы URL. Скажем, например, мы собираемся запустить стресс-тест нагрузки на Google, который мы можем запустить ...
curl -s "http://google.com?[1-1000]"
Это сделает 1000 звонков в Google, т. Е.
http://google.com?1
http://google.com?2
http://google.com?3
...
http://google.com?1000
Более подробно это обсуждается на Как быстро провести стресс-тестирование веб-сервера с помощью curl.
Вам нужно будет настроить различные тесты:
- Обычный тест, симулируйте пользователей так, как они будут себя вести. Вы будете внедрять время обдумывания (без http-ярости между страницами). Одним из способов является запись веб-сеанса, чтобы у вас было реалистичное время для завершения/чтения каждой страницы. Нагрузка будет идти шаг за шагом, пока вы не достигнете средней текущей нагрузки в производстве
- Тест на разрыв: То же, что и раньше, но добавляйте нагрузку, пока не получите первую ошибку http 500. Цель состоит в том, чтобы узнать, какой нагрузкой вы можете управлять, пока она не сломается
- Длительное испытание. Первый сценарий выполняется в течение 12 часов, чтобы убедиться, что у вас нет утечки памяти или снижения производительности с течением времени.
После/перед каждым тестом вы должны вернуть платформу, как и прежде: восстановить базу данных, перезагрузиться, чтобы очистить память и кэш.
Вы также реализуете разминку: запускайте сценарии один раз перед реальным тестом, чтобы веб-страницы компилировались, устанавливалось соединение с базой данных. Иначе, первый звонок всегда будет плох в вашей статистике.
Вы можете добавить сложность, например:
- используйте разные сценарии (посетители/гости, участники), которые будут работать по-разному.
- Имитация различий пропускной способности
- Рандомизируйте искомое слово и подумайте время.
Еще одна важная вещь: вы ДОЛЖНЫ сохранить все завершенные сценарии, чтобы иметь возможность сделать их снова точно таким же образом, чтобы можно было сравнить производительность с предыдущими тестами.
Если вы просто хотите проверить, как он обрабатывает несколько соединений, вы можете использовать что-то вроде Siege . Все еще не уверен, что это отличная мера, но он по крайней мере скажет вам, как вы обрабатываете несколько соединений
Я использовал openSTA .
Это использует относительно простой язык сценариев.
Вы можете легко тестировать веб-сервисы/серверы и писать свои собственные скрипты.
Это позволяет вам объединять сценарии в тесте любым удобным для вас способом и настраивать количество итераций, количество пользователей в каждой итерации, время нарастания для представления каждого нового пользователя и задержку между каждой итерацией. Тесты также могут быть запланированы в будущем.
Это с открытым исходным кодом и бесплатно.
Он создает ряд отчетов, которые можно сохранить в электронную таблицу. Затем мы используем сводную таблицу, чтобы легко проанализировать и построить график результатов.
Я использовал LoadRunner и раньше, но это довольно дорого, я также использовал инструменты выпуска Microsoft Team Tester, которые включают систему, которая проводит нагрузочные тесты. Я был очень доволен тем, как работал этот инструмент, и вы могли расширить тесты, используя .net, который был более простым синтаксисом, чем LoadRunner.
Версия загрузчика, которую мы использовали, также не могла обрабатывать наш сайт AJAX (это было в 2000 году, поэтому я уверен, что этот инструмент был улучшен к настоящему времени)
Мы используем WAPT , и это работает очень хорошо. Простота установки и всего несколько сотен долларов. LoadRUnner смехотворно завышен и абсолютно недоступен для всех, кроме Forutune 500.
Это зависит от того, насколько сложен ваш сценарий.
Чтобы правильно имитировать нагрузку реальных пользователей на ваш сервер, вы должны попытаться смоделировать то, что на самом деле делают пользователи. Если ваши пользователи просто нажмут на URL-адрес сервера, подойдет любой из бесплатных/простых инструментов.
Для веб-сайта, который немного сложнее, вы хотели бы использовать инструмент, который поможет вам с динамической корреляцией значений, параметризацией и т.д. Вы можете использовать Load-Runner и тому подобное, я предпочитаю использовать WebLOAD знак равно.