Новый Relic & JMeter — тестирование идеальной производительности

В продолжение этой замечательной вводной статьи, недавно опубликованной на Nettuts +, эта статья показывает, как вы можете поднять New Relic на новый уровень. New Relic — это инструмент для мониторинга производительности, но как насчет тестирования производительности, прежде чем начать работу. Вот тут и приходит JMeter. В этом руководстве вы увидите, как мы можем провести стресс-тестирование нашего приложения при реалистичной нагрузке, а также объединить результаты JMeter и New Relic, чтобы дать вам уверенность в производительности ваших приложений перед выпуском в производственную среду.

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

Демо-приложение

Прежде чем мы сможем начать использовать New Relic и JMeter, нам нужно простое приложение для тестирования производительности! Итак, давайте напишем простое приложение Ruby Sinatra, которое имеет сервис, который мы можем протестировать. Я не буду слишком вдаваться в создание этого приложения, так как вы можете прочитать о Sinatra в других статьях о Nettuts +.

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

Вот код, который определяет сервисы:

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

Привязка к новой реликвии

Получение отчетов вашего приложения в New Relic — очень простой процесс. Новая Relic поддерживает Ruby, Python, PHP, Java и другие платформы, предлагая простые для всех руководства. В случае с Ruby an Sinatra это буквально четыре шага:

• Добавьте гем ‘newrelic_rpm’ в ваш GemFile и установите пакет.
• В вашем основном app.rb, где мы определили маршрут сервиса выше, добавьте строку «require ‘newrelic_rpm’».
• Загрузите файл «newrelic.ini» из своей учетной записи в New Relic и поместите в папку конфигурации в своем приложении.
  (Убедитесь, что для режима мониторинга установлено значение «истина» для разработки, если она выполняется локально.)
• Сделайте резервную копию вашего приложения и посмотрите его в списке в New Relic!

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

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

Экран можно разбить следующим образом:

1. Время отклика — это среднее время ответа на вызовы по вашему приложению.
2. Apdex — новая метка Relics для удобства клиентов. Оценка больше 1 указывает на подавляющее большинство пользователей
   запросы падают в разумные сроки. Апдекс может быть полезен для оповещения, когда он падает ниже установленного номера.
3. Пропускная способность — количество запросов в минуту (RPM) к вашему приложению.
4. Веб-транзакции — различные маршруты, доступные в вашем приложении. Они заказаны по самым трудоемким запросам.
5. Коэффициент ошибок — процент запросов, вызвавших ошибку. Вы можете просмотреть и отладить отдельные ошибки здесь.

Что такое JMeter?

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

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

Установка и использование

Установка довольно проста, и здесь мы перечислим инструкции для Mac и Linux.

Mac OS X

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

Linux

На компьютере с Linux просто загрузите его со страницы загрузок JMeter. Затем просто следуйте инструкциям.

Все платформы

После того, как у вас есть основной пакет JMeter, нам также нужно установить стандартный набор плагинов. В частности, позже мы будем использовать один плагин, поэтому нам нужно добавить его, чтобы иметь возможность его использовать. Стандартный набор плагинов можно получить по этой ссылке: http://jmeter-plugins.org/downloads/file/JMeterPlugins-1.0.0.zip После загрузки извлечения в пакет JMeter, который находится по адресу: «/ usr / local / Cellar / jmeter / «на Mac и везде, где вы установили его в Linux.

Анализ в новой реликвии — сначала нам нужен план испытаний JMeter!

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

Теперь давайте установим базовый URL для наших запросов. Щелкните правой кнопкой мыши «План тестирования» на левой панели и выберите «Добавить -> Элемент конфигурации -> HTTP-запрос по умолчанию» . Теперь мы можем ввести наш базовый URL здесь вот так.

Теперь мы можем добавить количество потоков или «пользователей» нашей системы. Для этого снова щелкните правой кнопкой мыши «План тестирования» и выберите «Добавить -> Темы (пользователи) -> Группа потоков» . Затем мы можем ввести пользователей, в данном случае 20. Убедитесь, что вы выбрали опцию «Счетчик циклов навсегда», так как это позволит нам позже контролировать время и количество запросов с помощью плагина.

Получив группу потоков, мы можем теперь определить запросы, которые мы хотим сделать к нашему приложению, которое мы собираемся проверить на производительность. Для этого мы добавим «HTTP-запрос» в наш «План тестирования». Это можно найти, щелкнув правой кнопкой мыши на «Группе потоков» и выбрав «Добавить -> Сэмплер -> HTTP-запрос» . Затем мы можем определить запрос, чтобы сделать в панели, как показано ниже.

Вы можете видеть, как нам не нужно определять базовый URL, как мы делали это ранее, и вместо этого просто нужно добавить путь для запроса. В этом случае путь к нашему ответу «example / 1». Вы также заметите, что я пошел дальше и добавил два других запроса вместе с панелями результатов и графиков, которые мы будем использовать для анализа результатов тестов. К этому моменту вы уже можете добавлять элементы, и их можно легко найти в меню по их именам. Основными интересами являются «Таймер формирования пропускной способности» и «Составной график».

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

Таким образом, зайдя и добавив каждую строку, вы можете определить объем запроса и срок его выполнения. Затем мы можем просмотреть наши результаты, используя «составной график», который показывает количество транзакций, совершенных в секунду, в зависимости от времени ответа на наши запросы. Это требует минимальной настройки, просто добавив два графика, которые мы будем объединять, затем в настройках составного графика добавьте графы, которые нам нужны, примерно так:

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

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

Давайте сравним эти результаты с сервисом с задержкой в ​​три секунды. Как это справится с увеличением нагрузки? Чтобы переключиться на пример два, щелкните правой кнопкой мыши на примере один и выберите переключатель. Это отключит этот запрос, затем переключится на второй пример, и это включит его. Не забудьте нажать значок «Очистить все» (широкая кисть) вверху, чтобы очистить результаты последнего запуска, а затем нажать кнопку воспроизведения.

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

Новая Реликтовая Аналитика

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

Опять же, я не буду вдаваться в настройку New Relic, поскольку это описано в других недавних статьях о Nettuts + (см. Здесь ). Но как только ваше приложение подключено, это просто случай генерации нагрузки через JMeter и входа в New Relic для просмотра результатов. Для этого запуска я настроил Shaping Timer, чтобы наша загрузка работала в течение 30 минут, увеличивая количество запросов с пяти до 10, а затем 15 в секунду. Это должно дать нам разумный трафик на New Relic.

После запуска теста JMeter мы можем взглянуть на New Relic, который, как мы теперь видим, имеет статистику трафика, следующего через приложение.

Это ясно показывает увеличение количества запросов, достигая пика около 400 запросов в минуту (RPM), а время ответа остается стабильным в течение трех секунд. Мы можем углубиться в статистику и изучить сделку, которую мы совершаем. Если мы перейдем к представлению веб-транзакций, мы увидим анализ, который New Relic сделал только для этой части приложения. Если бы в коде, который обрабатывал запрос, было больше слоев, таких как методы вызова других систем для получения данных перед их представлением пользователю, мы бы увидели больше неполадок.

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

New Relic также предоставляет отличный отчет о данных ваших приложений, который называется Масштабируемость. Этот отчет может быть очень полезен для мониторинга способности ваших приложений справляться с возрастающей нагрузкой. На графике показано ваше время ответа на запросы в минуту, и вы можете четко увидеть, есть ли какое-либо ухудшение времени ответа по мере их увеличения. Это отличный инструмент, к которому следует часто обращаться как при тестировании производительности, так и при мониторинге производительности вашего производственного приложения.

В нашем примере ниже ясно, что приложение способно поддерживать время отклика в три секунды даже при увеличении оборотов в минуту.

Новая Реликвия также предоставляет другую точку зрения — Capacity. Это позволяет нам смотреть, сколько из доступных ресурсов использует наше приложение. Он указывает разработчику, достаточно ли количество экземпляров, обслуживающих ваше приложение, для обработки нагрузки, которую вы получаете. Это жизненно важно для обеспечения того, чтобы вы не работали на предельной пропускной способности и имели возможность обрабатывать любые всплески трафика, которые могут возникнуть за пределами вашего обычного транспортного потока. Новая Relic хорошо суммирует страницу, рядом с анализом нашего приложения, который, как мы видим, хорошо справляется даже с этим единственным примером.

Вывод

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

Используя великолепные инструменты, предоставляемые New Relic, вы можете не только следить за своим приложением в режиме онлайн в режиме реального времени, но и использовать его набор инструментов и применять его для собственного автономного анализа. Это придаст вам, разработчику, уверенности в вашем продукте, как в процессе его разработки, так и после его выпуска в эксплуатацию.