Наша команда столкнулась с недостатками инструментов нагрузочного тестирования, и, в конце концов, было решено разработать собственный сервис. Основные сложности:

• Если это сервис — для серьезной нагрузки цена слишком высока
• Если это утилита — результат зависит от скорости канала компьютера/сервера с которого проводился тест
• Повторяющиеся запросы не отражают реальной скорости, так как кэширование есть на самых разных уровнях начиная от CPU и заканчивая базой данных

Надеюсь, «велосипед» будет интересен и другим — сначала я опишу что уже работает, потом можно будет обсудить дальнейшие фичи.

Что уже сделано?

• Можно тестировать задания из списка url, до 20 штук
• Каждая url может содержать один или несколько случайных параметров, задаваемых с помощью функции $RND
• Тест запускается с множества серверов, на каждом из которых работает только 8 потоков
• Тестирование можно проводить из 4х регионов AWS — Ирландия, Восток/Запад США, Токио
• Тесты до 200 потоков мы готовы предоставлять бесплатно

Для теста открываем форму, где указываем email, заполняем URL, выбираем количество потоков тестирования, регион и начинаем тест.

*** UPDATE ***
Я вижу много смелых хабравчан ставит задание на 200 потоков. Если предположить, что 1 страница выдается за 1 секунду то это соответствует посещаемости >100К посетителей в час. Обычные проекты, в том числе наши, умирают от таких тестов.

Через минуту будет готов ваш результат (для примера посмотрите отличный результат — тестирование example.net). Как видим, 200 потоков позволяет генерировать более 1000 запросов в секунду — все зависит от скорости связи с тестируемым сервисом, и. собственно, скорости ответа.

Если вы готовы похвастаться вашим результатом на нашем сайте — можете нажать кнопку Public result. Для того, чтобы показать его своим коллегам достаточно отправить ссылку.

Что тестировать?
Статические ресурсы, картинки, скрипты должны отдаваться с CDN. Тестировать их скорость отдачи имхо не имеет смысла, нужно тестировать только общую скорость загрузки страницы, к примеру с помощью старого доброго http://tools.pingdom.com/fpt/

Loadme сосредотачивается на тестировании кода страниц / методов api и т.п… Тестировать nginx отдающий 1x1.gif с помощью этого инструмента конечно можно, но практической пользы нет, и nginx от этого даже не согреется.

Чтобы определиться, какие же страницы являются самым узким местом, лучше всего воспользоваться newrelic. В отличие от популярного google analytics он также позволяет отслеживать статистику запросов ботов, и строить запросы по количеству операций, приходящихся на ту или иную страницу, а также какая из страниц больше всего портила впечатление пользователей по индексу apdex.
Как известно, ложка дегтя бочку меда портит, и если ваше приложение будет тормозить на каких-то даже относительно редких действиях это вполне может влиять и на популярные легковесные операции.

Как работают редиректы?
Редиректы выполняются; мы их активно используем это для тестирования одного из наших сайтов wikiart.org, реализовав на нем функцию «перейти на случайную картину».

Почему важно тестировать несколько url?
Для тестирования взаимного влияния популярных быстрых страниц и медленных (к примеру, поиска)

Зачем нужен $RND?
Синтаксис — $RND(from,to).
К примеру, http://someshop.com/search?from=$RND(0,1000)&to=$RND(1000,10000) будет генерировать произвольные запросы по поиску товаров по цене начиная от 0 до 1000 и заканчивая от 1000 до 10000. Это дает возможность оценить реальную мощность поиска.
К примеру, популярный украинский магазин Rozetka тратит в среднем 5 секунд на поиск смартфонов по случайной цене:
http://loadme.socialtalents.com/Result/ViewById/56108a645b5f1700481cc21d, что является весьма далеким от идеала результатом.
Амазон справляется с этой задачей принципиально лучше — значительное количество ошибок в результате, скорее всего, является защитой от ddos

Дальнейшие планы

Post, put, delete запросы
Нужная штука, однозначно, есть в планах.

Авторизация
Достаточно ли будет поддержки куки, с тем чтобы первый запрос логинил тест под случайным пользователем (для чего понадобится поддержка со стороны сервера), и дальнейшая работа пойдет от имени этого пользователя?

Ступенчатые тесты
Скажем, провести серию тестов: 25%, 50%, 75% и 100%, и увидеть разницу в скорости.

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

Регулярный тест по расписанию
Повторять тест каждый день / неделю и высылать отчет на email.
Также можно предоставиьт какой-нибудь webhook для иницирования существующего теста из кода (к примеру, после обновления)

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

Подтверждение собственности домена
Ограничение не более 200 агентов на 1 домен существует ровно для того чтобы никто не поверг в ddos чужой сайт. Для своего сайта вы можете создать еще один поддомен и протестировать его еще раз.
В будущем, однако, нужно будет сделать подтверждение доменов с помощью CNAME записи или файла с определённым именем.

Существующие конкуренты

Loadimpact.com — для нормального нагрузочного теста, хотя бы 100 запросов в секунду, потребуется 1500 так называемых «виртуальных юзеров» — каждый из них загружает страницу 1 раз в 15 секунд. Стоит такой пакет на данный момент $299 в месяц.

loader.io — отличный сервис, платный пакет всего $99 в месяц. Очень гибкие настройки URL — можно завать методы, куки, хедеры, но нам не хватило рандомизации теста.