Компонентная среда разработки инструментария нагрузочного тестирования Евгений Рачинский. СПбГУ в сотрудничестве с  Siemens Corporate Technology СПбГУ
Нагрузочное тестирование Изучение поведения многопользовательской системы под нагрузкой Цели: Оценка характеристик производительности системы под нагрузкой Поиск узких мест в системе Планирование производительности Средства Моделирование нагрузки Инструментарий генерации нагрузки и измерения показателей  Методы анализа результатов
Инструментарий Существующие средства нагрузочного тестирования не обладают достаточной гибкостью и адаптивностью Решение: создание платформы для разработки инструментария нагрузочного тестирования Области применения Нагрузочное и стресс тестирование с использованием нестандартных протоколов Поддержка статистических методов в нагрузочном тестировании Автоматизация нагрузочного тестирования  Поддержка  continues integration process
Типовая архитектура Load Control Measurements Input Output Monitoring Load injectors Controller Analysis Scenario definition Workload definition SUT
Области расширения Компонентная среда ( OSGi/Java ) Архитектура основанная на  plug -ins API,  точки расширения   Platform/ framework Scenario Workload Protocol and measurements Statistics and analysis Load test management
Сценарий Симулирует поведение пользователей Java  классы Сценарий Транзакция (шаг) Запрос Иерархичность ,  модульность Идентификация частей сценария Генерация кода сценариев Отладка ( Eclipse) Scenario Transaction Request 1 * 1 *
Сценарий (пример) 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   ); } }
Нагрузка Нагрузка это частота обращений к системе Определяется через количество виртуальных пользователей   И среднее значение и распределение времени ответа Request time Virtual users Think time time Request  rate ... Virtual users SUT λ µ
Определение нагрузки (пример) 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)); }
Поддержка сетевых протоколов и измерений Любой протокол, имеющий клиент c кие  Java  библиотеки  Регистрация значений : Время исполнения Ошибки протокола / приложения Проткол-специфические измерения (размер пакета, время установления соединения,  DNS  время и т . п.) Инструментирование библиотек протоколов Поддержка протоколов интегрируется в базовые классы сценариев
Run -time  статистика и журналирование Измерения собираются в статистики : Среднее значение Частота событий Счетчики Определенная пользователем Масштабирование значений  Среднее значение на разных масштабах времени Расширяемый «движок» статистики Filter /Pipe design patter n Журналирование  Набор  CSV  файлов , Apache Derby Формат определен протоколом
Управление тестом Пользовательский интерфейс Eclipse RCP UI Command line  Подготовка теста Eclipse Java IDE, PDE Рабочее окружение  Eclipse Исполнение теста   и   мониторинг   Графики статистики Расширяемость Eclipse plugin-ins Chart API (JFree chart) ANT tasks Results export Load test controller Load test definition
Компоненты   платформы 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
Замечания по реализации Высокая производительность агентов Сложность точного измерения времени в  Java  ( msec, nanosec ) Синхронизация потоков виртуальных пользователей  Синхронизация времени в распределенной среде Интенсивный поток данных (измерений) Сложность использование  Java  аннотаций   и рефлексии
Приложения платформы Стандартное нагрузочное тестирование HTTP, SOAP, RMI Сложные сценарии Различные протоколы в одном сценарии Симуляция вероятностного поведения пользователя (С BMG) Генерация кода сценариев (из трасс или моделей) Нагрузочное тестирование и регулярная сборка  ANT task  для определения и запуска теста 0.9 0.3 0.7 1.0 0.5 1.0 0.5 0.1 End Start
Приложения платформы (2) Генерация заданной нагрузки Пуассоновский поток запросов Автоуправление нагрузкой в зависимости от текущих показателей производительности Измерение среднего значения времени ответа с заданным доверительным интервалом  Автоматический поск максимальной пропускной способности системы ( max TPS) Симуляция пульсирующей нагрузки
Максимальная пропускная способность системы Load Response time Load Throughput (TPS) Average response time  Throughput  ( TPS)
Анализ результатов  Пакеты статистической обработки S - Plus (R  statistics) Д исперсионный анализ   сравнение производительности альтернативных конфигураций системы Корреляционный анализ Вывод параметров аналитических моделей  ( очереди ) Построение моделей «черного ящика»
Спасибо за внимание!
Backup slides
Descriptive statistics example – KPI VS. load
Тестирование производительности распределенных систем Web server Application  Server Application Server Database Authentication Service LDAP Tickets Reservation Service Доступно для тестирования под нагрузкой Недоступно для тестирования под нагрузкой
Approach overview Perform load test and collect measurements Windmill + dynamic workload Determine response time distribution Statistical tests Lognormal, Gamma, Weibull distributions Fit response time distribution parameters Non-parametric models (cubic splines) Setup runtime simulator Analytical or table representation of the model Performance load test of a SUT
Results comparison SUT with real service SUT with emulated service Legend:
time

Компонентная среда разработки инструментария нагрузочного тестирования

  • 1.
    Компонентная среда разработкиинструментария нагрузочного тестирования Евгений Рачинский. СПбГУ в сотрудничестве с Siemens Corporate Technology СПбГУ
  • 2.
    Нагрузочное тестирование Изучениеповедения многопользовательской системы под нагрузкой Цели: Оценка характеристик производительности системы под нагрузкой Поиск узких мест в системе Планирование производительности Средства Моделирование нагрузки Инструментарий генерации нагрузки и измерения показателей Методы анализа результатов
  • 3.
    Инструментарий Существующие средстванагрузочного тестирования не обладают достаточной гибкостью и адаптивностью Решение: создание платформы для разработки инструментария нагрузочного тестирования Области применения Нагрузочное и стресс тестирование с использованием нестандартных протоколов Поддержка статистических методов в нагрузочном тестировании Автоматизация нагрузочного тестирования Поддержка continues integration process
  • 4.
    Типовая архитектура LoadControl Measurements Input Output Monitoring Load injectors Controller Analysis Scenario definition Workload definition SUT
  • 5.
    Области расширения Компонентнаясреда ( OSGi/Java ) Архитектура основанная на plug -ins API, точки расширения Platform/ framework Scenario Workload Protocol and measurements Statistics and analysis Load test management
  • 6.
    Сценарий Симулирует поведениепользователей Java классы Сценарий Транзакция (шаг) Запрос Иерархичность , модульность Идентификация частей сценария Генерация кода сценариев Отладка ( Eclipse) Scenario Transaction Request 1 * 1 *
  • 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.
    Нагрузка Нагрузка эточастота обращений к системе Определяется через количество виртуальных пользователей И среднее значение и распределение времени ответа Request time Virtual users Think time time Request rate ... Virtual users SUT λ µ
  • 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.
    Поддержка сетевых протоколови измерений Любой протокол, имеющий клиент c кие Java библиотеки Регистрация значений : Время исполнения Ошибки протокола / приложения Проткол-специфические измерения (размер пакета, время установления соединения, DNS время и т . п.) Инструментирование библиотек протоколов Поддержка протоколов интегрируется в базовые классы сценариев
  • 11.
    Run -time статистика и журналирование Измерения собираются в статистики : Среднее значение Частота событий Счетчики Определенная пользователем Масштабирование значений Среднее значение на разных масштабах времени Расширяемый «движок» статистики Filter /Pipe design patter n Журналирование Набор CSV файлов , Apache Derby Формат определен протоколом
  • 12.
    Управление тестом Пользовательскийинтерфейс Eclipse RCP UI Command line Подготовка теста Eclipse Java IDE, PDE Рабочее окружение Eclipse Исполнение теста и мониторинг Графики статистики Расширяемость Eclipse plugin-ins Chart API (JFree chart) ANT tasks Results export Load test controller Load test definition
  • 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
  • 14.
    Замечания по реализацииВысокая производительность агентов Сложность точного измерения времени в Java ( msec, nanosec ) Синхронизация потоков виртуальных пользователей Синхронизация времени в распределенной среде Интенсивный поток данных (измерений) Сложность использование Java аннотаций и рефлексии
  • 15.
    Приложения платформы Стандартноенагрузочное тестирование HTTP, SOAP, RMI Сложные сценарии Различные протоколы в одном сценарии Симуляция вероятностного поведения пользователя (С BMG) Генерация кода сценариев (из трасс или моделей) Нагрузочное тестирование и регулярная сборка ANT task для определения и запуска теста 0.9 0.3 0.7 1.0 0.5 1.0 0.5 0.1 End Start
  • 16.
    Приложения платформы (2)Генерация заданной нагрузки Пуассоновский поток запросов Автоуправление нагрузкой в зависимости от текущих показателей производительности Измерение среднего значения времени ответа с заданным доверительным интервалом Автоматический поск максимальной пропускной способности системы ( max TPS) Симуляция пульсирующей нагрузки
  • 17.
    Максимальная пропускная способностьсистемы Load Response time Load Throughput (TPS) Average response time Throughput ( TPS)
  • 18.
    Анализ результатов Пакеты статистической обработки S - Plus (R statistics) Д исперсионный анализ сравнение производительности альтернативных конфигураций системы Корреляционный анализ Вывод параметров аналитических моделей ( очереди ) Построение моделей «черного ящика»
  • 19.
  • 20.
  • 21.
  • 22.
    Тестирование производительности распределенныхсистем Web server Application Server Application Server Database Authentication Service LDAP Tickets Reservation Service Доступно для тестирования под нагрузкой Недоступно для тестирования под нагрузкой
  • 23.
    Approach overview Performload test and collect measurements Windmill + dynamic workload Determine response time distribution Statistical tests Lognormal, Gamma, Weibull distributions Fit response time distribution parameters Non-parametric models (cubic splines) Setup runtime simulator Analytical or table representation of the model Performance load test of a SUT
  • 24.
    Results comparison SUTwith real service SUT with emulated service Legend:
  • 25.

Editor's Notes

  • #2 Уважаемые участники конференции, хочу попредведствовать вас и представиться. Меня зовут Евгений Рачинский. Последние четыре года я работаю аналитиком по вопросам инженерии производительности в компании Siemens в городе Мюнхене. Одновременно с этим Я работаю над диссертацией псвященной методам тестирования производительности клиент серверных систем. Отдел в котором я работю занимается консультациямивнутренних заказчиков, а так же занимается исследовательской Деятельностью.
  • #3 Сначала немного о производительности в целом. Воо бще вопросы производительноти были поднеяты достаточно Давно. В телекоме анализ и планирования производительности хорошо развиты уже напротяжении нескольких десятков Лет. Во всем виноват обычный телефон, в начале 20 ого века встал вопрос как заранее узнать сколько абонентов Сможет одновременно обработать станция и сколько в среднем придется ждать соединения. Математическая теория была разработана Агнером Эрлангом и называется теорией массового обслуживания. Поискав в интернете по клчючевым вопросам производительность Вы скорее в сего попадете на страницы по теории СМО. Для не подготовленного человека будет не просто понять как это Приложить в повседневной разработке ПО. Да и для подготовленного это не простая задача требующая серьезного опыта. Да простят меня математики, но наиболее популярные методы в повседневной разработке это профилирование и нагрузочной тестирование. В профилировании изучается время выполнения отдельных участков кода, а так же синхронизация и взаимодействие потоков. В Случае же нагрузочного тестирования нас интересует как ведет себя система (и ее компоненты) обслуживая много пользователей. Итак Тепрель про слайды Вообще в программной инженении термин Производительность и анализ производительности весьма универсален и применяется ко многим вещам, хотя у всех Этих вещей есть общее – время. Производительность это время! Среди этих вещей можно Выделить аналитической моделирование (сети очередей и симуляция), профилирование, проблемы синхронизации распределенных процессов, Так же сюда относят надежность систем.
  • #4 По этому вопросу можно долго рассуждать и спорить, но в целом я бы охарактеризовал Существующие средства как мотолитные продукты. Эти средства достаточно четко Указывают как и что нужно делать и соодветственно предоставляют поддержку только для своего КАК. Ну например моделирование нагрузки, в большестве средств предоставляется Довольно ограниченная возможность. Или например интеграция нагрузочного тестирования в ночную сборку. Важный момент! Все определяется в коде! Количество конфигурационных файлов сведено к минимуму. В частности Параметры конкретного теста определены в коде. Конфигурация конкретного теста это набор скомпилированных программных Компонент. Таким образом мы решили создать собственную платформу для разработки таких средств. Платформа реализует общую функциональность для таких тулов, а вот все остальное может разработать Тести инжененр. Наш подход: не просто еще один инсрумент нагрузочного тестирования, а платформа для создания таких инструментов. Таки образом, тест инженер получил возможность подгонять свой инструмент для конкретных нужд. Кочеться еще отдельно сказать об инструменарии на коленке. К сожалению в этой области это опасно. Сам инструмент должен быть выскопроизводительным, иначе он может вностить существенные погрешности в измрения Которые сложно отследить. Помимо прочего данная платформа служит для экспериментов с методиками нагрузочного тестирования и оценки производительности в целом. Про области применения:
  • #5 Эта высоко уровневая архитектура свойственна для большенства средств нагрузочного тестирования. Наша платформа не исключение. Основные элементы это Контроллер и сеть распределенных Инжегторов, или генераторов или агентов. Контороллер занимается управлением то есть запуском, Котролем и котролем теста, распределенным управлением агентами, мониторингом измерений.
  • #6 Теперь рассмотрем поподробнее области расширения, то есть те аспекты, в которых требуется Гибкость и адаптивность. Точнее, это те аспекты которые могут варьироваться в зависимости от Тестируемой системы, целей тестирования, процесса тестирования. Сценарий – возможность реализации любой логики поведения польователя Нагрузка - возможность симулировать любые шаблоны нагрузки Протоколы и измерения – использование любых требуемых протоколов коммуникации между LA и SUT Статистика и анализ – применение статистических методов (особенно во время проведения нагрузочного теста) Управление процедурой теста – запуск, контроль, автоматизированный запуск например из ANT скрипта Теперь рассмотрим каждый аспект в отдельности
  • #7 Почему не деклараьивно : унас добалвяется еще один интерпретатор. Ограниченность, сложные условные переходы требуют сложного интерпретатора. Скриптовый язык Скриптовые языки достаточно медленны . Разрабатывать свой, ЗАчем? ! Все это возможно сделать на Java . Плюсы + любая логика + готовые инструменты для генерации ( eclipse, AST) + простота + готовая среда разработки и отладки Каждый запрос это отдельный класс это существенно облегчает разработку и Упрощает алгоритм генерации из моделей. Помимо всего прочего это служит для Идентификации артефактов сценария. (На монирое исполнения сценария пользователь Однозначно понимает что за объект (идетификация, генерация)) Может быть имплементирована любая пользовательская логика Но пока что все что рассказывал не имеет никакого отношения к производительноти Игде же тут производительность? Это стоит продемонстировать на примере.
  • #8 Так а где же здесть производительность, пока что подобные сценарии характирны и для Функционального тестирования. Тут без примера сложно обойтись. Некоторые аспекты в примере опущены (например инициализация) Логика RUN Но главное вот оно метод RUN в каждом классе. Он будет измерен . Инструментарий ( ассистирование написание кода, шаблоны )
  • #9 С точки зрения сервера, нагрузка это частота обращений к нему. Таким образом, нагрузка, на стороне клиента (то есть генератора нагрузки) Представим как можно генерировать нарузку. Несколько готовых потоков, которым мы командуем через промежутки времени старт. Определяется как количество виртуальных пользоватлей и время ожидания между итерациями сценария (или шага или даже запроса). Но для высокой частоты мы получаем проблему синхронизации . Поэтому проще в виде закрытой систымы , когда запросы на выполнение возвращаются в пул. Как это выглядит на практике. Паралельные ряды это Виртуальны пользователи, полоски это время испольнения запроса к серверу включающее все. Промежутки между ними это время обдумывания. Спроецировав начало запросов на единую ось времени мы получим частоту обращений. Она то и будет нагрузкой. Поэтому опредение нагрузки как количество пользователей системы не однозначно (хотя определяет средную нагрузку) Распределение времени обдумывания так же имеет важное значение, при использовании константных Значений поток В кнце хочу отметить, что зачастую под термином нагрузка подразумевается поведение пользователя . В данном докладе Я понимаю под этим термином много пользовательскую нагрузку и все что с этим связано. А определение поведения Пользователя называю сценарием , так как это не имеет прямого отношения к произваодительноти.
  • #10 Как определяется нагрузка. По сути, это функция от времени , которая принемает значения количество виртуальных Пользоватлей и время обдумывания для всех виртуальных пользователей (точнее говоря распределений вероятностей) Таким образом мы можем задать любую зависимость .
  • #11 Любой протокол, имеющий клиент c кие Java библиотеки Для каждого запроса регистрируются значения. Тип значений зависит от протокола. Время испольнения это общее что есть у всех протоколов. AspektJ для токо чтобы померить отдельные части времени исполнения запроса в уже скомпилированных библиотеках.
  • #12 Единичное отдельное измерение нам не интересно. Для этого собираем в статистики, которые статистически характеризуют измеряемые значения. Примеры Представим что мы измеряем среднее время ответа на интервале в 30 сек. Мы берем сумму всех измереий и делим на Количество этих измеренй. И так для каждого интервала в 30 сек. А теперь представми что мы хотим Узнать среднее время ответа на интервале в один час. А у нас только по 30 сек. Что бы посчитать за час, на нужно Всю сумму поделить на общее колво измерений за весь час. Таким образом храним == { сумма зн a чений, интервал времени, количество значений, сумма квадратов значений }
  • #13 На контроллере мы активно используем Eclipse и OSGi. Расширяемость за счет плагинов. Интеграция с другими средствами нпример PDE , EMF,
  • #14 Как же все это фунционирует . Big picture . Во первых есть два конейнера : агент и контороллер. Не случайно использую слово конейнер, потому что, по сути это application servers . В коненерах есть сервисы, которые обеспечивают базовае функции для генерации нагрузки , сбора измерений, управление Удалнными агентами и так далее. И на конец есть конкретная конфигурация теста, в виде компоненты OSGi , то есть по сути это jar пакеты \\с мета информацией. Перед началом теста, эти пакеты автоматически деплоятся (инстолируеются на удаленных агентах) Среди них … ТО есть перед тестом конструируется приложение нагрузочного тестирования.