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

Меня зовут Вячеслав Смирнов, я ускоряю и тестирую инфраструктурные сервисы в Miro. Ещё я развиваю сообщество нагрузочников в telegram: делюсь там кое-какой экспертизой. В частности, если выполнять тесты производительности регулярно, по несколько раз в день, то вскоре в популярном хранилище тестов InfluxDB фильтровать результаты тестов производительности становится сложно. Сегодня я расскажу про 12 шагов, как можно ускорить InfluxDB. Основным из них является ускорение с помощью nginx кэширования. Пример использования кэширующего nginx, в качестве источника данных для Grafana можно найти тут. Все остальные примеры, которые мы будем разбирать я вынес сюда. А слайды оставил здесь.

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

В предыдущей статье я рассказал о подготовке данных для тестирования, что данные лучше генерировать, а не клонировать. Теперь стоит подробно разобрать, как их генерировать. Есть несколько подходов к генерации данных: c SQL, Python, сериализацией. У всех из них есть свои плюсы, минусы и особенности, которые стоит учитывать.

Как добиться необходимого контроля, удобства и даже скорости при подготовке тестовых данных для микросервисов и тестов производительности? В каких случаях лучше не генерировать XML и JSON файлы с помощью конкатенации строк? Зачем анализировать статистику по SQL запросам?

Меня зовут Вячеслав Смирнов, и я ускоряю дистанционное банковское обслуживание юридических лиц, а еще поддерживаю чат QA — Load & Performance в Телеграм, где сообщество инженеров по тестированию производительности обсуждает тестирование нагрузки.

Статья получилась длинной, поэтому сегодня я расскажу про подготовку тестовых данных для тестирования производительности и про то, как с помощью SQL, Pandas и Java эти данные готовить. Поговорим про анализ метрик и логов с точки зрения данных и с использованием InfluxDB, Grafana и прочих инструментов, А ещё о том, как может выглядеть хороший отчет по системе, в которой много данных. В следующих частях перейду к генерации и анализу тестовых данных для нагрузки.

• Apache.JMeter
• Gatling
• LoadRunner Enterprise
• Yandex.Tank

1. Назначение плагина «HTTP Request Tail»

• выполнить группу GET-запросов паралельно;
• выполнить 1000 GET-запросов, не создавая 1000 компонентов HTTP Request;
• протестировать сайт, активно использующий AJAX, Adobe Flash, Adobe AIR, SilverLigth, ...

• посчитать среднее качество полноты извлечения ссылок на встроенные ресурсы html-парсерами Apache.JMeter;
• проверить правда ли извлечение ссылок в Apache.JMeter 3.0 стало более полным;
• испытать в деле плагин CsvLogWriter.

Постановка задачи

• Microsoft SQL Server;
• Microsoft Office Excel;
• Комплекс sql-запросов, организованный в проект SQLProfilerReportHelper;
• Инструмент нагрузочного тестирования с возможностью выполнить sql-запрос (JMeter, Visual Studio Ultimate, ...);

1. запустить SQLProfilerReportHelper, кликнуть по кнопкам;
2. выполнить выборку записей из таблиц-отчётов, скопировать результаты в буфер обмена;
3. запустить Microsoft Office Excel, вставить записи из буфера в автоматически форматируемую таблицу и сохранить документ-отчёт.