[lang_en]Using Apache Access Logs with JMeter[/lang_en][lang_ru]Использование Apache access log с JMeter[/lang_ru]

Перевод статьи посвященной созданию нагрузочных тестов с помощью JMeter и Apache logs.
Автор: Geoff Mottram (geoff at minaret dot biz). (English version on http://minaret.biz/tips/jmeter.html)

Перевод: Sergey N Lukin (sergey at look-in dot net)

Опубликовано автором 21-го сентября 2004.

Этот документ и все сопутствующее программное обеспечение поставляет «как есть» («as is»), при этом не предусматривается никаких гарантий, явных или подразумеваемых, включая, но не ограничиваясь, подразумеваемую гарантию товарного состояния при продаже и пригодности для использования в конкретных целях, а также любые иные гарантии. Весь риск в отношении качества и производительности программы ложится на вас. Если программа окажется с дефектом, вы принимаете на себя расходы по всему необходимому обслуживанию, восстановлению и исправлению.

Содержание

Введение

Советы JMeter Tips
Использование файлов Apache Log (логи)
Фильтрация ваших логов
Продолжительность и нагрузка
Создание тестового плана
Запуск теста
Анализ результатов

Введение

Это документ описывает некоторые советы о том как использовать логи апача (apache logs) в качестве исходного материала для тестового плана JMeter.

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

Хотелось бы отметить что после того как была написана статья появился Tomcat Access Log Sampler (и Access Log Sampler). Этот sampler может так же читать логи в формате Apache common log и создавать запросы к вашему web приложению. У автора не было возможности попробовать этот sampler, но многие советы из этой статьи будут также применимы. В частности, ты должен подготовить логи для каждого тестового потока.

Файлы

Скачать архив (и копия на этом сайте). Архив содержит:

файл	описание
filter.sh	Шелл-скрипт, фильтрует исходных лог и выделяет 10 минутный набор запросов.
makeplan.pl	Создает тестовый план JMeter по логам
results.jmx	Тестовый план для обработки результатов тестирования.
runtest.sh	Шелл-скрипт, для запуска теста в режиме командной строки, сохраняет результаты в текстовый файл.
sample.jmx	Пример тестового плана с одним потоком и одним запросом созданный с помощью скрипта makeplan.pl.

Советы по JMeter

Следующие советы могут быть полезны в отношении JMeter:

1. JMeter хранит тестовые планы как XML. Значит ты можешь создавать тестовые планы используя текстовый редактор или шелл (shell) скрипты.
2. Созданный и сохраненный тестовый план (.jmx) с помощью JMeter может быть разделен на части с помощью текстового редактор. Это может быть полезно для использования их скриптам.
3. Имей ввиду, что когда используются логи как источник то тестовые планы могут быть большими, очень большими. Например, план с 2800 запросами требует 256 MB RAM и не может быть загружен в JMeter GUI без увеличения памяти под JVM.
4. Запускай свои тесты в консольном режиме — что бы уменьшить размер требуемой памяти.(опция -n в JMeter).
5. У всех JMeter Listeners’ов (такие как Aggregate Report) есть Filename поля. Используя его можно загрузить и посмотреть результаты теста.
6. Создай тестовый план, которые содержит только Listeners для анализа результатов теста. Для примера смотри — results.jmx.
7. Можно запустить JMeter-тест с удаленного сервера, на котором даже нет GUI. Потом скопируй результат.jtl на рабочую станцию с GUI для анализа результатов.
8. Если вы планируете запускать JMeter под IBM AIX, необходимо изменить скрипт запуска jmeter в папке bin — закомментировать опцию -XX, она не поддерживается на IBM’s JVM.
9. Во время работы теста, ты можешь из браузера сделать дополнительный запрос, что бы почувствовать как система реагирует. Эта субъективная оценка поможет сравнить желаемое и реальное время обработки запроса. Но помни, что эти дополнительные запросы не фиксируются в отчетах, и не отражаются в результатах тестирования.

Следующие советы наиболее применимы когда используются Apache access log в качестве исходного материала для тестов. (для примера смотри sample.jmx ).

1. Используй HTTP Request Defaults для указания имени сервера который тестируете, и не вноси эту и информацию в каждый запрос. Это поможет если придется менять имя сервера. Надо будет изменить только одну настройку, а не каждый запрос.
2. Используй Constant Throughput Timer когда используешь Apache log как исходный материал, что бы обеспечить частоту запросов как в исходных логах (подробнее смотри ниже). Постоянная скорость запросов применяется для каждого потока. В нашем примере каждый поток делает 10 запросов в минуту.
3. Используй Uniform Random Timer когда у тебя более одного потока и хочется предотвратить запуск всех потоков «волной». Без этого таймера все ваши потоки будут посылать запросы в одно и тоже время т.к. мы используем Constant Throughput Timer. Выберете значение Random Delay соответствующее значению в Constant Throughput Timer. В нашем примере Constant Throughput Timer установлен в 10 запросов в минуту. Это дает каждому запросу «окно» в 6 секунд, установи в Uniform Random Timer значение Random Delay Maximum в 6000 миллисекунд (6 секунд).
4. HTTP Cookie Manager действительно работает отлично и поддерживает множество cookie для каждого запущенного потока.

Используем Apache Log файлы

Файлы apache log это отличный исходный материал для создания нагрузочных тестов JMeter. Мы используем простой процесс преобразования текстовых лог файлов в тестовый план JMeter, потому что JMeter хранит тесты используя XML. Преимущество использования Apache access log — то что ты не строишь догадки о том как нагружается твой сервер — ты используешь готовую информацию.

С другой стороны, используя Apache log, ты ограничиваешься только GET запросами (т.к. логи не включают содержание запросов POST). И также не возможно эмулировать запросы, что возвращают 304 (Не изменен), это требует добавление в заголовок запроса даты/времени модификации страницы. Это можно сделать в самом JMeter самостоятельно, если есть такая необходимость.

Фильтрация Apache log

Тебе надо решить насколько большой тест желаешь, и извлечь подходящие запросы из лога. Я просмотрел статистику и графики созданные программой Webalizer, для определения когда сервер наиболее загружен (т.е. день и час). Решил, что 10 минут достаточная длительность теста, я использую filter.sh, который включен в эту документацию, для определения той 10-ти минутой части лога, что отражает наиболее загруженный час, и отфильтровываю запросы, которые меня не интересуют.

В моем случае, я удаляю также записи, что не содержат HTTP 200 (OK) и 320 (Moved Temporarily) ответы. В последнем случае, приложение выполняет тест cookie когда сессия стартует и пересылает пользователя на другой URL.

Если тестируешь приложение с базой (как я), вы должны найти способ выполнить login для тестовой сессии. Если используешь cookies, что бы отслеживать сессии, необходимо создать сессии для каждого потока в JMeter. Т.к. мое приложение выполняет автоматический логин по IP адресу, то я только сконфигурировал тестовый аккаунт с IP адресом компьютера с которого я планирую запускать тесты JMeter.

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

Длительность и нагрузка

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

Ты должен использовать не только Constant Throughput Timer для эмуляции реальной загрузки сервера, т.к. этот таймер будет запускать все потоки одновременно, в этом случае запросы нахлынут на сервер волной. Что бы решить эту проблему, ты должен добавить также Uniform Random Timer (JMeter таймеры аддитивны). Uniform Random Timer добавляет случайное число миллисекунд в каждый поток перед следующим запросом. Это значение может быть от 0 до Random Delay Maximum. Это значение пересчитывается каждый раз что делает тестирование более реалистичным. Значение Random Delay Maximum уставите таким же как частота в Constant Throughput Timer. Единственное что переведите «запросы в минуту» в миллисекунды.

В моем случае, десять запросов в минуту на поток работают как 6 секунда на запрос. Эти 6000 и должны быть выставлены в качестве Random Delay Maximum в Uniform Random Timer.

Я выбрал что 2800 запросов для моего 10 минутного теста. Использую 28 потоков, каждый поток сделает 100 запросов в 10 минут или 10 запросов в минуту. Это значение и было использовано в обоих таймерах. Если бы мы решили использовать 14 потоков, то каждый поток выполнил бы 200 запросов за 10 минут или 20 запросов в минуту.

Если захочешь запустить тест с уменьшенной нагрузкой, то есть послать меньшее количество запросов за тот же период. Например, для уменьшения нагрузки в 2 раза, ты можешь уменьшить количество запросов и кол-во потоков дважды. В моем случае это будет 1400 запросов и 14 потоков.

Для увеличения нагрузки, увеличь количество запросов посланные в тоже период времени и количество потоков. Для моего теста 125% увеличение требует 3500 запросов и 35 потоков.

Создание тестового плана

Скрипт makeplan.pl включает в себя документацию по использованию:

Usage: makeplan.pl [-h HOST] [-t THREADS] [FILE1] [FILE2] ...        Where: -h specifies the host name or ip address to test (default is "localhost").

-t specifies a non-zero number of threads to generate (default is 1).

Reads each FILE in succession (or standard input), generating a JMeter test plan to standard output.

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

Перенаправь вывод скрипта в файл с расширением .jmx — это и есть ваш тестовый план.

Для первичного теста, запустите makeplan.pl скрипт с небольшим логом. Загрузите этот тест файл в JMeter и запустите тест. Далее, проверьте результаты, для этого можете использовать View Results Tree Listener (его нужно добавить до запуска теста). После того как запустите тест, вы можете использовать Response data для точного просмотра того что вернулось от сервера.

Внимание, скрипт makeplan.pl не просто нарезает исходный файл на количество кусочком равное количеству поток. Он пытается расположить запросы примерно в том же порядке что они были в Apache log, каждый поток получает n-й запрос (n количество потоков).

Запуск теста

Ты можешь запустить свой полный тест используя runtest.sh скрипт. Перед использование укажи путь к папке «bin» внутри этого скрипта к твоей инсталляции JMeter.

Суть скрипта в следующей строке:

jmeter -n -t $DIR/$1.jmx -l $DIR/$1.jtl

Где $DIR твоя текущая директория, и $1 имя тестового плана. Опция -n, говорит JMeter запускаться в консольном режиме, опция -t указывает на тест что нужно запустить, -l указывает на выходной файл результатов.

Анализ результатов тестирования

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

Я решил что Aggregate Report наиболее удобный для анализа результата тестирования описанного здесь. Наиболее важный столбец называется «Average» и показывает среднее число миллисекунд, которые потребовались для обработки запроса. Столбец «rate» показывает как часто этот запросы был послан. Т.к. мы использует таймеры для ограничения скорости посылания запросов, то количество в этом столбце не отражает то как хорошо/плохо сервер обрабатывает запрос.

Для загрузки результатов теста, выбери Aggregate Report, далее в Filename, далее Browse... . Выбери файл с результатами и нажми Load. Для просмотра результатов в другом формате используйте остальные отчеты (listeners).