От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
Компонентная среда разработки инструментария нагрузочного тестирования
1. Компонентная среда разработки инструментария нагрузочного тестирования Евгений Рачинский. СПбГУ в сотрудничестве с Siemens Corporate Technology СПбГУ
2.
3.
4. Типовая архитектура Load Control Measurements Input Output Monitoring Load injectors Controller Analysis Scenario definition Workload definition SUT
5.
6.
7. Сценарий (пример) public class Service1Scenario extends WebScenario { Transaction1 transaction1 = new Transaction1(); Transaction2 transaction2 = new Transaction2(); public void run() { runTransaction( transaction1 ); sleep(1000); runTransaction( transaction2 ); } } public class Transaction1 extends WebTransaction { Request1 request1 = new Request1(); public void run() { runRequest( request1 ); } } public class Request1 extends WebRequest { public void run() { HttpResponse response = null ; response = getContext(). getClient().execute( url ); } }
8.
9. Определение нагрузки (пример) int maximumVirtualUsers = 15; int incrementInterval = 60; int incrementVirtaulUsersBy = 1; public IThinkTime getThinkTimeOnTime( long time) { return new ConstantThinkTime(1000); } public int getVirtualUserNumberOnTime( long time) { int vu = Math. min ( maximumVirtualUsers, ( int )((time/incrementInterval)+1)*incrementVirtaulUsersBy ); return vu; } int Amplitude = 5; //virtual users double Frequency = 1/60; //virtual users per second int VerticalShift = 10; //oscillate around public IThinkTime getThinkTimeOnTime( long time) { return new ExponentialThinkTime(1000); } public int getVirtualUserNumberOnTime( long time) { return ( int )(VerticalShift + Amplitude*Math. sin (Frequency*time)); }
10.
11.
12.
13. Компоненты платформы Scenario Workload Statistics filters definition Network protocol libraries Log format definition T est artifacts (OSGi bundles ) Remote deploy Legend : Platform Service Deployable component Agent container Scenario manager Virtual users manager Statistics service Log service Experiment session Service Controller container Workload manager Experiment workflow Remote agent management Run time statistics processing Results Repository
22. Тестирование производительности распределенных систем Web server Application Server Application Server Database Authentication Service LDAP Tickets Reservation Service Доступно для тестирования под нагрузкой Недоступно для тестирования под нагрузкой
Уважаемые участники конференции, хочу попредведствовать вас и представиться. Меня зовут Евгений Рачинский. Последние четыре года я работаю аналитиком по вопросам инженерии производительности в компании Siemens в городе Мюнхене. Одновременно с этим Я работаю над диссертацией псвященной методам тестирования производительности клиент серверных систем. Отдел в котором я работю занимается консультациямивнутренних заказчиков, а так же занимается исследовательской Деятельностью.
Сначала немного о производительности в целом. Воо бще вопросы производительноти были поднеяты достаточно Давно. В телекоме анализ и планирования производительности хорошо развиты уже напротяжении нескольких десятков Лет. Во всем виноват обычный телефон, в начале 20 ого века встал вопрос как заранее узнать сколько абонентов Сможет одновременно обработать станция и сколько в среднем придется ждать соединения. Математическая теория была разработана Агнером Эрлангом и называется теорией массового обслуживания. Поискав в интернете по клчючевым вопросам производительность Вы скорее в сего попадете на страницы по теории СМО. Для не подготовленного человека будет не просто понять как это Приложить в повседневной разработке ПО. Да и для подготовленного это не простая задача требующая серьезного опыта. Да простят меня математики, но наиболее популярные методы в повседневной разработке это профилирование и нагрузочной тестирование. В профилировании изучается время выполнения отдельных участков кода, а так же синхронизация и взаимодействие потоков. В Случае же нагрузочного тестирования нас интересует как ведет себя система (и ее компоненты) обслуживая много пользователей. Итак Тепрель про слайды Вообще в программной инженении термин Производительность и анализ производительности весьма универсален и применяется ко многим вещам, хотя у всех Этих вещей есть общее – время. Производительность это время! Среди этих вещей можно Выделить аналитической моделирование (сети очередей и симуляция), профилирование, проблемы синхронизации распределенных процессов, Так же сюда относят надежность систем.
По этому вопросу можно долго рассуждать и спорить, но в целом я бы охарактеризовал Существующие средства как мотолитные продукты. Эти средства достаточно четко Указывают как и что нужно делать и соодветственно предоставляют поддержку только для своего КАК. Ну например моделирование нагрузки, в большестве средств предоставляется Довольно ограниченная возможность. Или например интеграция нагрузочного тестирования в ночную сборку. Важный момент! Все определяется в коде! Количество конфигурационных файлов сведено к минимуму. В частности Параметры конкретного теста определены в коде. Конфигурация конкретного теста это набор скомпилированных программных Компонент. Таким образом мы решили создать собственную платформу для разработки таких средств. Платформа реализует общую функциональность для таких тулов, а вот все остальное может разработать Тести инжененр. Наш подход: не просто еще один инсрумент нагрузочного тестирования, а платформа для создания таких инструментов. Таки образом, тест инженер получил возможность подгонять свой инструмент для конкретных нужд. Кочеться еще отдельно сказать об инструменарии на коленке. К сожалению в этой области это опасно. Сам инструмент должен быть выскопроизводительным, иначе он может вностить существенные погрешности в измрения Которые сложно отследить. Помимо прочего данная платформа служит для экспериментов с методиками нагрузочного тестирования и оценки производительности в целом. Про области применения:
Эта высоко уровневая архитектура свойственна для большенства средств нагрузочного тестирования. Наша платформа не исключение. Основные элементы это Контроллер и сеть распределенных Инжегторов, или генераторов или агентов. Контороллер занимается управлением то есть запуском, Котролем и котролем теста, распределенным управлением агентами, мониторингом измерений.
Теперь рассмотрем поподробнее области расширения, то есть те аспекты, в которых требуется Гибкость и адаптивность. Точнее, это те аспекты которые могут варьироваться в зависимости от Тестируемой системы, целей тестирования, процесса тестирования. Сценарий – возможность реализации любой логики поведения польователя Нагрузка - возможность симулировать любые шаблоны нагрузки Протоколы и измерения – использование любых требуемых протоколов коммуникации между LA и SUT Статистика и анализ – применение статистических методов (особенно во время проведения нагрузочного теста) Управление процедурой теста – запуск, контроль, автоматизированный запуск например из ANT скрипта Теперь рассмотрим каждый аспект в отдельности
Почему не деклараьивно : унас добалвяется еще один интерпретатор. Ограниченность, сложные условные переходы требуют сложного интерпретатора. Скриптовый язык Скриптовые языки достаточно медленны . Разрабатывать свой, ЗАчем? ! Все это возможно сделать на Java . Плюсы + любая логика + готовые инструменты для генерации ( eclipse, AST) + простота + готовая среда разработки и отладки Каждый запрос это отдельный класс это существенно облегчает разработку и Упрощает алгоритм генерации из моделей. Помимо всего прочего это служит для Идентификации артефактов сценария. (На монирое исполнения сценария пользователь Однозначно понимает что за объект (идетификация, генерация)) Может быть имплементирована любая пользовательская логика Но пока что все что рассказывал не имеет никакого отношения к производительноти Игде же тут производительность? Это стоит продемонстировать на примере.
Так а где же здесть производительность, пока что подобные сценарии характирны и для Функционального тестирования. Тут без примера сложно обойтись. Некоторые аспекты в примере опущены (например инициализация) Логика RUN Но главное вот оно метод RUN в каждом классе. Он будет измерен . Инструментарий ( ассистирование написание кода, шаблоны )
С точки зрения сервера, нагрузка это частота обращений к нему. Таким образом, нагрузка, на стороне клиента (то есть генератора нагрузки) Представим как можно генерировать нарузку. Несколько готовых потоков, которым мы командуем через промежутки времени старт. Определяется как количество виртуальных пользоватлей и время ожидания между итерациями сценария (или шага или даже запроса). Но для высокой частоты мы получаем проблему синхронизации . Поэтому проще в виде закрытой систымы , когда запросы на выполнение возвращаются в пул. Как это выглядит на практике. Паралельные ряды это Виртуальны пользователи, полоски это время испольнения запроса к серверу включающее все. Промежутки между ними это время обдумывания. Спроецировав начало запросов на единую ось времени мы получим частоту обращений. Она то и будет нагрузкой. Поэтому опредение нагрузки как количество пользователей системы не однозначно (хотя определяет средную нагрузку) Распределение времени обдумывания так же имеет важное значение, при использовании константных Значений поток В кнце хочу отметить, что зачастую под термином нагрузка подразумевается поведение пользователя . В данном докладе Я понимаю под этим термином много пользовательскую нагрузку и все что с этим связано. А определение поведения Пользователя называю сценарием , так как это не имеет прямого отношения к произваодительноти.
Как определяется нагрузка. По сути, это функция от времени , которая принемает значения количество виртуальных Пользоватлей и время обдумывания для всех виртуальных пользователей (точнее говоря распределений вероятностей) Таким образом мы можем задать любую зависимость .
Любой протокол, имеющий клиент c кие Java библиотеки Для каждого запроса регистрируются значения. Тип значений зависит от протокола. Время испольнения это общее что есть у всех протоколов. AspektJ для токо чтобы померить отдельные части времени исполнения запроса в уже скомпилированных библиотеках.
Единичное отдельное измерение нам не интересно. Для этого собираем в статистики, которые статистически характеризуют измеряемые значения. Примеры Представим что мы измеряем среднее время ответа на интервале в 30 сек. Мы берем сумму всех измереий и делим на Количество этих измеренй. И так для каждого интервала в 30 сек. А теперь представми что мы хотим Узнать среднее время ответа на интервале в один час. А у нас только по 30 сек. Что бы посчитать за час, на нужно Всю сумму поделить на общее колво измерений за весь час. Таким образом храним == { сумма зн a чений, интервал времени, количество значений, сумма квадратов значений }
На контроллере мы активно используем Eclipse и OSGi. Расширяемость за счет плагинов. Интеграция с другими средствами нпример PDE , EMF,
Как же все это фунционирует . Big picture . Во первых есть два конейнера : агент и контороллер. Не случайно использую слово конейнер, потому что, по сути это application servers . В коненерах есть сервисы, которые обеспечивают базовае функции для генерации нагрузки , сбора измерений, управление Удалнными агентами и так далее. И на конец есть конкретная конфигурация теста, в виде компоненты OSGi , то есть по сути это jar пакеты \\с мета информацией. Перед началом теста, эти пакеты автоматически деплоятся (инстолируеются на удаленных агентах) Среди них … ТО есть перед тестом конструируется приложение нагрузочного тестирования.