Доклад Сергея Журина на конференции SQA Days-21 www.sqadays.com

1. Software quality assurance days
21 Международная конференция
по вопросам качества ПО
sqadays.com
Москва. 26–27 мая 2017
Сергей Журин
Performance-lab. Москва, Россия
s.zhurin@pflb.ru
Нагрузочное тестирование: Нестандартные методы
анализа потока данных в приложениях.

2.  Введение
 Описание ситуации
 Предпосылки к задаче
 Основная часть
 Стандартные средства анализа потока данных
 Нестандартные средства
 Примеры проектов
Содержание

3. Описание:
 Есть система, которая что-то делает
 В этой системе существует некоторый поток
данных
 Чтобы обрабатывать этот поток данных
требуются ресурсы
Проблема:
 Нам нужно получить некоторую информацию о
потоке данных
Описание ситуации

4. Поиск проблемы:
 Рост времени отображения страницы
 Появление ошибок (Out of memory exception)
Прогнозирование:
 Расширение торговой сети
 Смена версии ПО, железа
 Hot season
Предпосылки к задаче

5. Стандартные средства:
 Консультация у разработчика
 Встроенный мониторинг БД
 Профилирование кода приложения
 Анализ трафика (сниффинг)
 Самостоятельная разработка инструмента мониторинга
Нестандартные средства:
 Модификация скомпилированного кода приложения
Средства для анализа потока данных

6. Обратится с вопросом к разработчику или к
компетентному лицу
Плюсы:
 Знает свое приложение
Минусы:
 Разработчика нет (уволился)
 У разработчика нет времени
Стандартные средства: Разработчик

7. В каждой нормальной Базе Данных можно настроить
мониторинг
В основном выгружается топ sql запросов по
некоторым параметрам
Плюсы:
 Уже реализовано
 В 95% случаях этого хватает
Минусы:
 Иногда нужно больше информации
 Чем больше информации собирается, тем больше
ресурсов требуется
Стандартные средства : Мониторинг БД

8. Плюсы и минусы аналогичны мониторингу БД
Плюсы:
 Уже реализовано
 В 95% случаях этого хватает
Минусы:
 Иногда нужно больше информации
 Чем больше информации собирается, тем
больше ресурсов требуется
Стандартные средства: Профилирование кода

9. Сниффер – утилита, которая позволяет
анализировать сетевой трафик
Плюсы:
 Ловит все
 Поддерживает большинство сетевых протоколов
Минусы:
 Нужен парсер трафика
Стандартные средства: Анализ трафика

10. Лучше пользоваться уже готовыми
инструментами
Плюсы:
 В итоге Вы получаете то, что хотите
Минусы:
 Время разработки
 Не всегда это можно сделать, нужны
исходники
Стандартные средства: Самостоятельно

11. Модифицировать скомпилированный код:
 C/C++ – бинарные файлы “.dll”, “.exe”
 Java – byte code “.class”
 C# – “.net”
Плюсы:
 Мы можем работать в любой ситуации
 Не нужна декомпиляция
Минусы:
 Большая сложность
Модификация скомпилированного кода

12.  ASM – быстрая и активно развивается
 BCEL – относительно медленная, больше не разрабатывается
 Javaassist – самый простой вариант, чтобы начать
 CGLIB – надстройка над ASM, для большего удобства
 Byte buddy – генерирует классы посредством DSL. Активно развивается
Модификация byte code’а: Обзор инструментов

13. Причины непопулярности:
 Отсутствие опыта работы и выглядит страшно
 Сложно понять, что изменять
Скомпилированный код сильно отличается от исходного.
Есть несложные алгоритмы для:
 Написания заглушек
 Анализа потока через приложение
Модификация byte code’а: Теория

14. В каждый public метод вставить код:
если вызов в thread’е первый, то логируем
параметры вызова и возвращаемое значение
Что получаем:
 Методы, которые вызываются системой в драйвере
 Параметры вызова этих методов
 Возвращаемые методами значения
Модификация byte code’а: Логирование входа
Система 1
java драйвер
Система 2

15. До и после вызова ко внешней системе вставить лог:
 Параметров вызова
 Возвращаемого значения
Трудность при логировании выхода:
 Нужно определять, вызов каких методов логировать
Кандидаты на лог:
 Вызов native методов – вызовы библиотек dll (OCI
драйвер для Oracle)
 Вызов других jar
Модификация byte code’а: Логирование выхода
Система 1
java драйвер
Система 2

16. Что будет если главную БД
заменить на другую?
Примеры из практики: Переход на новую БД
Параметры к sql-запросам?
 Мониторинг БД:
 Не содержит параметры запросов
 Подробный мониторинг – убивает БД
 Профилирование: не содержит параметры вызова
 Анализ трафика: нельзя найти параметры из-за мусора

17.  Три application server’а
 Запуск ночью заданий для
 Расчета цен на следующий день
 Дозаказ товаров
 Подготовка отчетов
 Задача: построить зависимость количества
sql-запросов (по типам) от времени и
сравнить ее с другими метриками
Примеры из практики: Анализ ночного профиля

18. Модификация скомпилированного
применяется для:
 Сделать свою вундервафлю, когда
нет исходников
 Профилирования в условиях, когда
нормальный профилировщик
нельзя использовать
 Анализ сложности кода
 Безопасность
 Проверки на хеш приложения
 Обфускация
Техническая информация: что еще?

19. Презентацию выполнил:
Журин Сергей.
s.zhurin@pflb.ru
Инженер по производительности ПО
Performance lab.
Вопросы и ответы