Рубрика «jmeter»

Привет!

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

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

Сам процесс нагрузочного тестирования в своём сознании я делю на несколько этапов:

Нагрузочное тестирование, история автоматизации процесса - 1
Читать полностью »

Пару слов для начала

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

  1. Apache JMeter – инструмент для нагрузочного тестирования, который способен проводить тесты для JDBC-соединений, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP и TCP из коробки и еще множество других протоколов и решений, используя различные плагины.
  2. Yandex.Tank – это облачный инструмент для нагрузочного тестирования, использует различные генераторы нагрузки, в том числе и JMeter.
  3. Yandex.OverLoad – сервис для удобного мониторинга и анализа серверов под нагрузкой.

Читать полностью »

image
Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:

Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  452793 requests in 10.03s, 58.30MB read
Requests/sec:  45133.28
Transfer/sec:      5.81MB

elixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  184703 requests in 10.02s, 28.57MB read
Requests/sec:  18441.79
Transfer/sec:      2.85MB

Как жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.

Читать полностью »

Автоматизация нагрузочного тестирования: связка Jmeter + TeamCity + Grafana - 1

Изображение: Flickr

В нашем блоге на Хабре мы продолжаем рассказывать о построении DevOps-культуры в компании — например, в одном из последних топиков мы описывали то, какие задачи решаем с помощью системы SaltStack. Сегодня речь пойдет о другой интересной теме — автоматизации нагрузочного тестирования с помощью связки нескольких готовых инструментов.Читать полностью »

Однажды встретились JMeter и незнакомка… - 1
Кадр из фильма «Дом у озера». Встреча (www.kinopoisk.ru)

Джим ещё не знал, как подойти к ней, с чего начать разговор и на каком языке его вести. Но он видел многое, владел языками и имел в рукаве не один козырь. И будучи уверенным в помощи верных друзей (это мы с вами) и забыв про сомнения, шёл на встречу судьбе.

Ниже рассказ о том, как Джим завоёвывал снова и снова сердце незнакомой системы. Не подумайте, что незнакомок было несколько. Она была одна, единственная, но такая разная, и от того истории будут следовать одна за другой.
Читать полностью »

TailSampler — паралельная отправка GET-запросов в Apache.JMeter - 1
 

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

Плагин упрощает загрузку встроенных ресурсов, позволяет параллельно выполнять указанные GET-запросы. Делая тест максимально близким к работе браузера по составу загружаемых ресурсов и по способу загрузки этих ресурсов.

TailSampler выручает если нужно:

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

Читать полностью »

Среднее качество полноты извлечения ссылок на встроенные ресурсы html-парсерами Apache.JMeter
Среднее качество работы парсеров (для семи сайтов)

Предлагаю:

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

Как гласит народная мудрость: Верить верь, но…
Читать полностью »

Введение

Наверняка каждый, кто пользовался стандартными листенерами в JMeter, сталкивался со следующими ограничениями:

  • стандартные листенеры не позволяют получить подробную информацию по всем запросам, прописанным в тест плане;
  • стандартные листенеры выводят информацию в XML — формате, что осложняет дальнейший анализ логов средствами Excel и IPython.

Чтобы обойти данные ограничения, было принято решение переработать формирование лог-файлов с помощью нового плагина CsvLogWriter.
Читать полностью »

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.Читать полностью »

Так сложилось, что последние полгода я активно занимался тестами производительности и мне кажется, что в этой области IT царит абсолютное непонимание происходящего. В наше время, когда рост вычислительных мощностей снизился (vertical scalability), а объем задач растет с прежней скоростью, проблема производительности становится всё острее. Но прежде, чем броситься на борьбу с производительностью, необходимо получить количественную характеристику.

Краткое содержание статьи:

Предыстория

Однажды, путешествуя в поезде, я захотел посчитать, каково расстояние между столбами электропередач. Вооружившись обычными часами и оценивая среднюю скорость поезда 80-100км/ч (25 м/с), я засекал время между 2-мя столбами. Как ни странно, этот наивный метод давал очень удручающие результат, вплоть до 1.5-2 кратной разницы. Естественно метод несложно было исправить, что я и сделал, достаточно было засечь 1 минуту и посчитать количество столбов. И не важно, что мгновенная скорость на протяжении минуты может варьироваться и даже не важно посчитаем мы последний столб или минута истечет посередине, потому как измерений вполне достаточно для требуемого результата.
Смысл теста в том, чтобы получить убедительные для себя и для других измерения.

Тесты «на коленке»

Эта история мне напоминает то, что происходит с тестированием производительности в Software Engineering. Достаточно частое явление — запуск 1-2 тестов, построение графиков и получение выводов о scalability система. Даже, если есть возможность применить МНК или узнать стандартную ошибку, это не делается за «ненадобностью.» Особенно интересная ситуация, когда после этих 2 измерений, люди обсуждают насколько быстрая система, как она масштабируется и сравнивают её с другими системами по личным ощущениям.
Конечно, оценить, насколько быстро выполняется команда, не сложно. С другой стороны, быстрее не значит лучше. Системы ПО имеют свыше 10 различных параметров, от hardware на котором они работают до input, которые вводит пользователь в разные моменты времени. И зачастую 2 эквивалентных алгоритма могут давать совершенно разные параметры масштабируемости в разных условиях, что делает выбор совсем не очевидным.

Недоверие к тестам

С другой стороны результаты измерений всегда остаются источником спекуляций и недоверий.
— Вчера мы меряли было X, а сегодня 1.1*X. Кто-то что-то менял? — 10% — это нормально, у нас теперь больше записей в БД.
— При проведении теста был отключен антивирус, скайп, анимация заставки?
— Не-не, для нормальных тестов нам надо закупить кластер серверов, установить микросекундную синхронизацию времени между ними… удалить ОС, запускать в защищенном режиме…
— Сколько пользователей мы поддерживаем? У нас 5000 зарегистрированных пользователей, вдруг 20% из них залогинится, надо запускать тесты с 1000 параллельными агентами.

Читать полностью »