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

Для нагрузочного тестирования существует ряд инструментов и сегодня мы рассмотрим один из них - простой и мощный Curl Loader.

Установка

Установка Curl Loader очень проста (главное требование - Linux/Unix среда). Для начала нужно скачать сымые свежие исходники с сайта разработчиков:
http://sourceforge.net/projects/curl-loader/files/

После этого, распаковываем и устанавливаем:

tar -xvf curl-loader-.tar.gz
cd curl-loader-
make
make install

По умолчанию Curl Loader компилируется в режиме дебага. Для того, что-бы выключить дебаг и улучшить производительность тестов можно сделать следующее:

make cleanall
make optimize=1 debug=0
make install

Запуск тестов

Запуск тестов выполняется с помощью утилиты curl-loader и передачи ей в параметр конфигурационного файла с помощью опции -f:

curl-loader -f bulk.conf

Создадим конфигурационный файл (с именем test.conf) для самого простого тестирования следующего содержания:

########### GENERAL SECTION ################################

BATCH_NAME= test
CLIENTS_NUM_MAX=50
CLIENTS_NUM_START=10
CLIENTS_RAMPUP_INC=5
INTERFACE   =eth0
NETMASK=16
IP_ADDR_MIN= 192.168.0.192
IP_ADDR_MAX= 192.168.0.192
IP_SHARED_NUM=1
CYCLES_NUM= -1
URLS_NUM= 1

########### URL SECTION ####################################

URL=http://google.com/
URL_SHORT_NAME="Google.com"
REQUEST_TYPE=GET
TIMER_URL_COMPLETION = 5000
TIMER_AFTER_URL_SLEEP = 500

В этом файле мы сконфигурировали тест для тестирования главной страницы google.com с 50 одновременными клиентами. Начинается тестирование с 10 клиентов. Каждую секунду прибавляется еще 5 клиентов, пока не достигнем 50. После сохранения этого файла запускаем Curl Loader:

sudo curl-loader -f test.conf

На экране появится статистика, обновляемая в реальном режиме:

Кроме этого, по окончании тестирования, Curl Loader создает три файла:

• test.log - информация об ошибках и трассировка
• test.txt - статистика загрузки
• test.ctx - статистика в разрезе виртуального клиента

В распакованном архиве Вы сможете найти папку conf-examples, в которой лежат конфигурационные файлы примеры для выполнения нагрузочных тестов.

Конфигурационные файлы

Конфигурационные файлы позволяют создавать достаточно сложную логику выполенения тестов (авторизация, отправка формы, загрузка файлов и т.д.). Файлы состоят из двух секций: GENERAL и URL.

Список параметров конфигурационных файлов:

Секция GENERAL

• BATCH_NAME - название теста, используется в качестве имени для файлов отчетов
• CLIENTS_NUM_MAX - максимальное количество клиентов
• CLIENTS_NUM_START - начальное количество клиентов (сразу после запуска теста)
• CLIENTS_RAMPUP_INC - количество клиентов, которые будут прибавляться каждую секунду
• IP_ADDR_MIN, IP_ADDR_MAX - множество IP адресов, которые будут принадлежать клиентам. Если значения в этих двух параметрах одинаковы, то все клиенты получат одинаковый IP адрес
• CYCLES_NUM - количество циклов при тестировании. Если установлено -1, то тесты повторяются бесконечно (прерывание исполнения Ctrl+C)
• URLS_NUM - количество URLов в секции описания адресов - см. ниже

Секция URL

• URL - первый параметр для каждой подсекции, указывает адрес для тестирования
• URL_SHORT_NAME - необязательное короткое имя ссылки (до 12 знаков)
• URL_USE_CURRENT - используется, когда параметр URL = “” (пустой), для указания того, что нужно применить URL из предыдущей операции. Полезно, когда необходимо послать POST запрос на результирующий URL с предыдущего GET запроса
• REQUEST_TYPE - тип HTTP запроса: GET, POST или PUT
• UPLOAD_FILE - полный путь к файлу для загрузки по указанной ссылке
• HEADER - используется для установки/перезаписи HTTP/FTP заголовков
• USERNAME, PASSWORD - эти параметры используются для операция авторизации. Их функциональность контролируется параметром FORM_USAGE_TYPE (см. полный список параметров)
• FORM_STRING - шаблон формы для отправки данных POST запросом. Содержит шаблон передаваемых параметров. Значения могут заполняться из внешнего файла, указываемого в параметре FORM_RECORDS_FILE.
• WEB_AUTH_METHOD, WEB_AUTH_CREDENTIALS - используются для HTTP аутентификации
• LOG_RESP_HEADERS, LOG_RESP_BODIES - включают/выключают журналирование заголовков и тел ответов

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

Полный список параметров можно посмотреть на официальном сайте

Тестирование действительно больших нагрузок

При тестировании с сотнями тысяч клиентов, обязательно учтите следующее:

1. Нужно увеличить ограничение количества сокетов до необходимого (например, ulimit -n 10000)
2. Можно также включить повторное использование сокетов (echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle and/or; echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse)

Вы пользуетесь подобными инструментами?

Статьи по теме

• Curl Loader