'

Мониторинг. Нагрузочное тестирование.

Понравилась презентация – покажи это...





Слайд 0

Мониторинг. Нагрузочное тестирование. fedor.malyshkin@magnetosoft.ru 2009.01.19


Слайд 1

Мониторинг. Обоснование. Предварительные вопросы: Сколько времени CPU потребляет Ваше приложение? Сколько памяти операционной системы оно использует? Сколько объектов оно хранит в своём хранилище? Сколько пользователей в системе сейчас? Сколько раз вызывается тот или иной метод (а так же каково его время выполнения)?


Слайд 2

Мониторинг. Обоснование. Причём, все эти показатели в разрезе времени…


Слайд 3

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


Слайд 4

Мониторинг. JMX. JMX (Java Management eXtension) Расширение Java машины (JVM) для предоставления средств мониторинга и управления. Впервые появилась как часть JRE/JDK в Java 1.5 (но можно использовать и в Java 1.4) Получила дальнейшее развитие в Java 6, Java 7…


Слайд 5

Мониторинг. JMX. Какую информацию JMX позволяет получать? Информацию о JMV (CPU, память, кол-во потоков, загруженные классы, Heap/Non Heap память, сборщик мусора и пр…) Информацию специфичную для приложения, которое выполняется в JVM.


Слайд 6

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


Слайд 7

Мониторинг. JMX.


Слайд 8

Мониторинг. JConsole. В комплекте с JDK идёт стандартный клиент для мониторинга JMX данных – jconsole.


Слайд 9

Мониторинг. JConsole.


Слайд 10

Мониторинг. JConsole.


Слайд 11

Мониторинг. JConsole.


Слайд 12

Мониторинг. Включение JMX. В Java 6 локальные соединения JMX активированы по-умолчанию. В Java 5, для JVM необходимо передать параметр -Dcom.sun.management.jmxremote=true Для активации удалённых подключений (с других машин) (в обеих версиях): -Dcom.sun.management.jmxremote.port=???? -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false


Слайд 13

Мониторинг. MAGNET. Подсистема мониторинга MAGNET. Кое-кто уже использует одну из подсистем платформы. Подсистему журналирования. Подключается просто: <dependency> <groupId>ru.magnetosoft.magnet</groupId> <artifactId>magnet-subsystem-management</artifactId> <version>0.1-SNAPSHOT</version> </dependency>


Слайд 14

Мониторинг. MAGNET. Подсистема позволяет собирать статистику по состояниям системы, по действиям выполняемым в ней. Накапливать и хранить статистику. Возвращать её в запрошенные диапазоны времени. Кроме того, она содержит утилиты для преобразования данных в форматы, специфичные для JMX протокола (и обратно).


Слайд 15

Нагрузочное тестирование. Обоснование. Симптомы необходимости внедрения нагрузочного тестирования: Через 3 месяца система начинает «деградировать». При пороге в 5 одновременных пользователей время ответа системы превышает 2 сек. Неожиданные ошибки конкурентного доступа. Зависание приложение системы при интенсивной работе. Непонятное потребление ресурсов при интенсивной работе или большом кол-ве пользователей.


Слайд 16

Нагрузочное тестирование. Правило #1. Нагрузочное тестирование – не однократная процедура.


Слайд 17

Нагрузочное тестирование. JMeter. JMeter - продукт для проведения нагрузочного тестирования. Особенности: Тестирование различных видов серверов: Web - HTTP, HTTPS SOAP/WS Database via JDBC LDAP Полностью портируем на все платформы (написан на Java). Многопоточность обеспечивает конкурентные замеры различных функций и обеспечивает эмуляцию виртуальных пользователей (VUser). Offline анализ результатов замеров. Высокая конфигурируемость.


Слайд 18

Нагрузочное тестирование. JMeter. На текущий момент рассмотрим возможности JMeter в области тестирования веб-сервисов. После (возможно в другой презентации) – тестирование веб-приложений.


Слайд 19

Нагрузочное тестирование. JMeter. Основные компоненты JMeter: Sampler – генератор запросов Listener – анализатор результатов выполнения запросов Controller – контроль выполнения Sampler’ов (циклы, условия, группы, время выполнения и прочее…)


Слайд 20

Нагрузочное тестирование. JMeter.


Слайд 21

Нагрузочное тестирование. Пример. Пример проведения нагрузочного тестирования будет продемонстрирован на модуле гетерогенного поиска (HS).


Слайд 22

Нагрузочное тестирование. Пример. Создаём под-проект по отношению к основному и размещаем код (код, скрипты, шаблоны) по тестированию в нём.


Слайд 23

Нагрузочное тестирование. Пример. Создаём заглушки модулей участников взаимодействия (FM, EM, Dict). Они эмулируют поведение своих реальных собратьев, но выдают псевдо-данные, которые предназначены для создания заполнения основного модуля. Для тех, кто не в курсе модуль HS, производит первоначальное извлечение данных из всех остальных модулей (подвергая их предварительной обработке), после чего переходит в основной режим работы. Режим выполнения сложных поисковых запросов.


Слайд 24

Нагрузочное тестирование. Пример. Создаём Ant (http://ant.apache.org/) скрипт, который выполняет ВСЮ работы в автоматическом режиме.


Слайд 25

Нагрузочное тестирование. Пример. Извлекает из maven репозитария все необходимые артефакты, включая заархивированные версии tomcat’а и jmeter. Это позволяет избежать предварительной настройки рабочих мест для проведения тестов. Распаковывает и конфигурирует извлечённые артефакты.


Слайд 26

Нагрузочное тестирование. Пример. Запускает все сконфигурированные артефакты в настроенном tomcat’е (с активированной поддержкой JMX). Ждёт старта и окончания предварительной синхронизации модулей. Запускает JMeter (как ant задачу), передавая ему в качестве параметров конфигурационный файл, в котором указано, что и как тестировать, а так же куда записывать результаты и логи.


Слайд 27

Нагрузочное тестирование. Пример. JMeter начинает выполнять тестовые запросы в соответствии с конфигурационным файлом (который также имеет расширение “.jmx”). Одновременно при этом он снимает показатели с JVM и записывает их в указанный лог-файл (XML формата).


Слайд 28

Нагрузочное тестирование. Пример. После выполнения нагрузочных тестов сгенерированные XML файлы подвергаются специальной обработке, после которой создаются XML и HTML файлы содержащие суммарную статистику теста.


Слайд 29

Нагрузочное тестирование. Пример. <?xml version="1.0" encoding="UTF-8"?> <jmxJvmDataStatistics> <satistics> <recordsCount>32</recordsCount> <measurementStarted>2009-01-18T13:31:25.062+0300</measurementStarted> <measurementFinished>2009-01-18T13:32:06.046+0300</measurementFinished> <measurementTime>40984</measurementTime> <jvmUptimeAtMeasurementEnd>143843</jvmUptimeAtMeasurementEnd> </satistics> <maxStateData> <processCPUUsagePerCent>26.7159257449927</processCPUUsagePerCent> <commitedVirtualMemorySize>52539392</commitedVirtualMemorySize> <heapMemoryUsage>9091984</heapMemoryUsage> <nonHeapMemoryUsage>23645624</nonHeapMemoryUsage> <threadCount>26</threadCount> <freePhysicalMemorySize>143142912</freePhysicalMemorySize> <freeSwapSpaceSize>686731264</freeSwapSpaceSize> </maxStateData> <minStateData> <processCPUUsagePerCent>0.000000944645308465716</processCPUUsagePerCent> <commitedVirtualMemorySize>49008640</commitedVirtualMemorySize> <heapMemoryUsage>8109448</heapMemoryUsage> <nonHeapMemoryUsage>22115016</nonHeapMemoryUsage> <threadCount>26</threadCount> <freePhysicalMemorySize>136445952</freePhysicalMemorySize> <freeSwapSpaceSize>679084032</freeSwapSpaceSize> </minStateData> <avgStateData> <processCPUUsagePerCent>5.81998057718807</processCPUUsagePerCent> <commitedVirtualMemorySize>51784704</commitedVirtualMemorySize> <heapMemoryUsage>8590992</heapMemoryUsage> <nonHeapMemoryUsage>23369054.25</nonHeapMemoryUsage> <threadCount>26</threadCount> <freePhysicalMemorySize>137923072</freePhysicalMemorySize> <freeSwapSpaceSize>680529664</freeSwapSpaceSize> </avgStateData> </jmxJvmDataStatistics>


Слайд 30

Нагрузочное тестирование. Пример.


Слайд 31

Нагрузочное тестирование. Пример. После этого тот же ant скрипт запускает стандартные JUnit тесты, которые анализируют итоговые XML файлы (а могут и оригинальные) и принимают решение – прошёл тест или нет.


Слайд 32

Нагрузочное тестирование. Приведённые скрипт (и его модификации для других продуктов) должен находиться в CI сервер и отслеживать: не повлияли ли внесённые изменения на требуемые показатели производительности.


Слайд 33

Нагрузочное тестирование. При разработке данные скрипт (и его модификации) могут использоваться для автоматизации основных задач (конфигурирование, развёртывание). Запуск самого JMeter’а можно проводит в ручную. Благодаря его богатому графическому интерфейсу процесс распределения нагрузки можно проследить более визуально.


×

HTML:





Ссылка: