Любой мало-мальски серьёзный веб-проект, будь то портал, сервис, интернет-магазин или что-то еще, нуждается в нагрузочном тестировании, поскольку именно оно позволяет выявить потенциальные “слабые места” и ошибки в коде, а также дает возможность оценить способно ли решение совместно с платформой выдержать планируемый размер аудитории проекта. Вы ведь планируете запуск и он должен быть успешен, верно?
Организовать нагрузочное тестирование можно самостоятельно, в локальном режиме, используя собственное серверное оборудование и инфраструктуру заказчика или разработчика, а можно пойти другим путем и протестировать проект с помощью облачных решений. Стоимость нагрузочного тестирования из облака значительно выигрывает у классических методов.
Одним из наиболее трудоемких моментов в организации процесса нагрузочного тестирования является разработка профиля нагрузочного тестирования, который должен предусматривать необходимое количество алгоритмов использования сайта, несколько типов пользователей и т.д. То есть, моделировать вариативность использования сайта, как в жизни. Это задача анализа, как будет использоваться сайт, сама по себе сложна, но вопрос скорее творческий и сейчас мы про него не говорим. Предположим, мы справились с ней и составили список сценариев использования сайта. Большой или маленький список, но все эти сценарии нужно обратить в скрипты тестирования, которые нужно не только написать, но и поддерживать в актуальном состоянии. Ведь тестирование проводится не единожды, проект-то мы запускаем всерьез, потому, всякий раз после внесения изменений, доработки или усовершенствования программного кода проекта мы обращаемся к тестированию. Все это требует и параллельного изменения тестовых скриптов.
Когда специалист по тестированию пишет такой скрипт, чаще используются технологии захвата http-траффика. Для корректной работы скрипта специалист вынужден привязывать его к серверным параметрам, которые берутся из сессии взаимодействия скрипта с сервером. Эту сессию обычно называют виртуальным пользователем. Для того, чтобы каждый новый виртуальный пользователь использовал бы при заходе на сервер корректные параметры сессии, нужно разрабатывать скрипты таким образом, чтобы они умели принимать от сервера различные параметры и могли бы их переиспользовать на всем протяжении этой сессии.
Но, когда у приложения множество серверных параметров, данная задача становится очень трудоемкой, поскольку тестировщику приходится поддерживать изменения в скрипте на уровне кода или вовсе заново перезаписывать скрипт, а затем и дорабатывать параметризацию.
Компания Hewlett Packard Enterprise предлагает SaaS решение StormRunner Load, умеющее эмулировать пользователей на уровне объектов браузера с помощью технологии TruClient. В этом случае скрипт представляет собой не поток http-трафика, а последовательность нажатия на кнопки и меню в браузере. Следить за серверными параметрами в таком случае становится ненужным, за ними следит браузер.
При запуске теста, очевидно, запускается браузер для каждого виртуального пользователя, то есть потребляются серьезные ресурсы, но к счастью, StormRunner Load, позволяет заказчику не задумываться о том, какой объем аппаратных мощностей ему необходим для осуществления нагрузочного тестирования, задачу управления ресурсами теста продукт берет на себя. Таким образом, головная боль с поиском ресурсов для нагрузочного теста снимается. Одновременно экономятся средства, выделяемые на закупку оборудования, если, конечно, компания может себе это позволить.
Любой, даже очень далекий от веб-программирования пользователь, может самостоятельно записать скрипт TruClient, поскольку для этого необходимо всего лишь включить кнопку записи и самостоятельно воспроизвести в браузере заданную последовательность шагов, которые будет выполнять данный скрипт. Разумеется, технология TruClient поддерживает работу с параметризацией скрипта для использования различных тестовых данных. Такой скрипт намного легче параметризовать и видоизменять в самом интерфейсе приложения, а перезаписывать его заново с нуля, о чем мы уже говорили выше, больше не требуется.
Решение HPE StormRunner Load в ходе внутреннего тестирования компанией HPE проверялось на полутора миллионах одновременных подключений к тестируемому серверу. Этого достаточно для большинства задач по нагрузочному тестированию даже в крупных проектах. Но даже если нужно протестировать веб-ресурс на сотне или тысяче одновременных подключений продуктом будет удобно пользоваться за разумную стоимость.
В решении каких практических задач может помочь HPE StormRunner Load? Это может быть проверка сайта на надежность перед началом маркетинговой кампании, когда возникает ажиотажный интерес к ресурсу. Если эта кампания успешна и вызывает массовые перепубликации, владельцы ресурса могут столкнуться с «хабраэффектом». В этом случае пользователи просто “повалят” сайт. Также возможен вариант, когда бизнес, которому принадлежит сайт, в определенные дни испытывает пиковые загрузки. Это может быть банк, предлагающий очень интересные и выгодные условия по вкладу, магазин, анонсирующий очередную очень выгодную акцию, новостной ресурс, опубликовавший какую-то сенсационную информацию и т.д. Решение по нагрузочному тестированию во всех этих случаях может помочь смоделировать для веб-ресурса прогнозируемую нагрузку, воспроизвести её заранее и проверить, как ресурс поведет себя при этом.
При желании можно не только проверить устойчивость сайта при прогнозируемой количестве сессий, но и рассчитать максимальный уровень нагрузки, которую способен выдержать веб-ресурс. Для вывода о том как прошел тест используется анализ прохождения пользовательских транзакций – последовательности действий пользователя в интерфейсе. По сути, время прохождения пользовательской транзакцию — это метрика успешного или неудачного прохождения сайтом нагрузочного тестирования. Вы заранее определяете, как быстро та или иная пользовательская транзакция должна завершиться, а задача StormRunner Load собрать статистику по этим пользовательским транзакциям. Наконец, решение позволяет эмулировать тип и качество сети, с которой “заходят” тестовые виртуальные пользователи. Это актуально для тех случаев, когда компания хотела бы адаптировать свой проект для обладателей разных типов устройств, включая мобильные, с разной скоростью и временной задержкой сетевого канала.
Тестировать с помощью HPE StormRunner Load можно и достаточно сложные веб-приложения, такие как, например, системы интернет-банкинга. Их работа связана с интеграциями, затрагивающими целый ряд других банковских систем и приложений (АБС, кредитный конвейер, карточки, CRM, и другие). В этом случае заказчик может самостоятельно определить, какое время должно отводиться на каждую пользовательскую транзакцию и заложить его в качестве SLA. Это позволит определить на каком этапе задержки в обработке пользовательской транзакции возникли и дополнительно, с помощью собираемых метрик производительности железа и ПО произвести анализ первопричины задержки.
Решение HPE StormRunner Load размещено в ЦОДе компании Hewlett Packard Enterprise и архитектурно состоит из двух частей. Первая находится на стороне HPE и отвечает за взаимодействие с пользователем и хранение всей его информации, тестовых сред и скриптов. Вторая часть инфраструктуры разворачивается в ЦОДах, где будут находиться машины для нагрузочного тестирования. Это облачные среды Amazon, Microsoft Azure, заказчик может выбрать ту, что подходит именно ему. Заказчик также может использовать и свои собственные нагрузочные стенды, находящиеся в своем ЦОДе или серверной.
Сегодня текущие заказчики HPE для решения задач нагрузочного тестирования используют классические продукты, такие как HPE LoadRunner и HPE Performance Center, которые разворачиваются на их территории, в ЦОДах компаний и успешно решают задачи нагрузочного тестирования любой сложности. Новое же решение HPE StormRunner Load решает задачу внешнего тестирования под высокими нагрузками и снимает вопрос поиска оборудования для стенда.
Организовать нагрузочное тестирование можно самостоятельно, в локальном режиме, используя собственное серверное оборудование и инфраструктуру заказчика или разработчика, а можно пойти другим путем и протестировать проект с помощью облачных решений. Стоимость нагрузочного тестирования из облака значительно выигрывает у классических методов.
Одним из наиболее трудоемких моментов в организации процесса нагрузочного тестирования является разработка профиля нагрузочного тестирования, который должен предусматривать необходимое количество алгоритмов использования сайта, несколько типов пользователей и т.д. То есть, моделировать вариативность использования сайта, как в жизни. Это задача анализа, как будет использоваться сайт, сама по себе сложна, но вопрос скорее творческий и сейчас мы про него не говорим. Предположим, мы справились с ней и составили список сценариев использования сайта. Большой или маленький список, но все эти сценарии нужно обратить в скрипты тестирования, которые нужно не только написать, но и поддерживать в актуальном состоянии. Ведь тестирование проводится не единожды, проект-то мы запускаем всерьез, потому, всякий раз после внесения изменений, доработки или усовершенствования программного кода проекта мы обращаемся к тестированию. Все это требует и параллельного изменения тестовых скриптов.
Когда специалист по тестированию пишет такой скрипт, чаще используются технологии захвата http-траффика. Для корректной работы скрипта специалист вынужден привязывать его к серверным параметрам, которые берутся из сессии взаимодействия скрипта с сервером. Эту сессию обычно называют виртуальным пользователем. Для того, чтобы каждый новый виртуальный пользователь использовал бы при заходе на сервер корректные параметры сессии, нужно разрабатывать скрипты таким образом, чтобы они умели принимать от сервера различные параметры и могли бы их переиспользовать на всем протяжении этой сессии.
Но, когда у приложения множество серверных параметров, данная задача становится очень трудоемкой, поскольку тестировщику приходится поддерживать изменения в скрипте на уровне кода или вовсе заново перезаписывать скрипт, а затем и дорабатывать параметризацию.
Компания Hewlett Packard Enterprise предлагает SaaS решение StormRunner Load, умеющее эмулировать пользователей на уровне объектов браузера с помощью технологии TruClient. В этом случае скрипт представляет собой не поток http-трафика, а последовательность нажатия на кнопки и меню в браузере. Следить за серверными параметрами в таком случае становится ненужным, за ними следит браузер.
При запуске теста, очевидно, запускается браузер для каждого виртуального пользователя, то есть потребляются серьезные ресурсы, но к счастью, StormRunner Load, позволяет заказчику не задумываться о том, какой объем аппаратных мощностей ему необходим для осуществления нагрузочного тестирования, задачу управления ресурсами теста продукт берет на себя. Таким образом, головная боль с поиском ресурсов для нагрузочного теста снимается. Одновременно экономятся средства, выделяемые на закупку оборудования, если, конечно, компания может себе это позволить.
Любой, даже очень далекий от веб-программирования пользователь, может самостоятельно записать скрипт TruClient, поскольку для этого необходимо всего лишь включить кнопку записи и самостоятельно воспроизвести в браузере заданную последовательность шагов, которые будет выполнять данный скрипт. Разумеется, технология TruClient поддерживает работу с параметризацией скрипта для использования различных тестовых данных. Такой скрипт намного легче параметризовать и видоизменять в самом интерфейсе приложения, а перезаписывать его заново с нуля, о чем мы уже говорили выше, больше не требуется.
Решение HPE StormRunner Load в ходе внутреннего тестирования компанией HPE проверялось на полутора миллионах одновременных подключений к тестируемому серверу. Этого достаточно для большинства задач по нагрузочному тестированию даже в крупных проектах. Но даже если нужно протестировать веб-ресурс на сотне или тысяче одновременных подключений продуктом будет удобно пользоваться за разумную стоимость.
В решении каких практических задач может помочь HPE StormRunner Load? Это может быть проверка сайта на надежность перед началом маркетинговой кампании, когда возникает ажиотажный интерес к ресурсу. Если эта кампания успешна и вызывает массовые перепубликации, владельцы ресурса могут столкнуться с «хабраэффектом». В этом случае пользователи просто “повалят” сайт. Также возможен вариант, когда бизнес, которому принадлежит сайт, в определенные дни испытывает пиковые загрузки. Это может быть банк, предлагающий очень интересные и выгодные условия по вкладу, магазин, анонсирующий очередную очень выгодную акцию, новостной ресурс, опубликовавший какую-то сенсационную информацию и т.д. Решение по нагрузочному тестированию во всех этих случаях может помочь смоделировать для веб-ресурса прогнозируемую нагрузку, воспроизвести её заранее и проверить, как ресурс поведет себя при этом.
При желании можно не только проверить устойчивость сайта при прогнозируемой количестве сессий, но и рассчитать максимальный уровень нагрузки, которую способен выдержать веб-ресурс. Для вывода о том как прошел тест используется анализ прохождения пользовательских транзакций – последовательности действий пользователя в интерфейсе. По сути, время прохождения пользовательской транзакцию — это метрика успешного или неудачного прохождения сайтом нагрузочного тестирования. Вы заранее определяете, как быстро та или иная пользовательская транзакция должна завершиться, а задача StormRunner Load собрать статистику по этим пользовательским транзакциям. Наконец, решение позволяет эмулировать тип и качество сети, с которой “заходят” тестовые виртуальные пользователи. Это актуально для тех случаев, когда компания хотела бы адаптировать свой проект для обладателей разных типов устройств, включая мобильные, с разной скоростью и временной задержкой сетевого канала.
Тестировать с помощью HPE StormRunner Load можно и достаточно сложные веб-приложения, такие как, например, системы интернет-банкинга. Их работа связана с интеграциями, затрагивающими целый ряд других банковских систем и приложений (АБС, кредитный конвейер, карточки, CRM, и другие). В этом случае заказчик может самостоятельно определить, какое время должно отводиться на каждую пользовательскую транзакцию и заложить его в качестве SLA. Это позволит определить на каком этапе задержки в обработке пользовательской транзакции возникли и дополнительно, с помощью собираемых метрик производительности железа и ПО произвести анализ первопричины задержки.
Решение HPE StormRunner Load размещено в ЦОДе компании Hewlett Packard Enterprise и архитектурно состоит из двух частей. Первая находится на стороне HPE и отвечает за взаимодействие с пользователем и хранение всей его информации, тестовых сред и скриптов. Вторая часть инфраструктуры разворачивается в ЦОДах, где будут находиться машины для нагрузочного тестирования. Это облачные среды Amazon, Microsoft Azure, заказчик может выбрать ту, что подходит именно ему. Заказчик также может использовать и свои собственные нагрузочные стенды, находящиеся в своем ЦОДе или серверной.
Сегодня текущие заказчики HPE для решения задач нагрузочного тестирования используют классические продукты, такие как HPE LoadRunner и HPE Performance Center, которые разворачиваются на их территории, в ЦОДах компаний и успешно решают задачи нагрузочного тестирования любой сложности. Новое же решение HPE StormRunner Load решает задачу внешнего тестирования под высокими нагрузками и снимает вопрос поиска оборудования для стенда.
