1. Java Performance
Подготовил: Артем Жданов.

2. Agenda
Теория
– Классические ошибки
– Выбор метрик
– Способы улучшения производительности
Пример
– Workflow система
– Проблемы и решения

3. У меня все медленно!
Что делать?

4. Первый шаг
«я вижу, что метод foo() реализован неэффективно»
«по профайлеру видно, что метод bar() – горячий и занимает
5%»
«по-моему, у нас тормозит БД, и нужно перейти с DB 1 на DB 2"
Правильный первый шаг:
1. Выбрать метрику
– ops/sec, transactions/sec
– время исполнения
– время отклика
2. Убедиться в корректности метрики
– релевантна (учитывает реальный сценарий работы приложения)
– повторяема

5. Метрики
Throughput, Bandwidth. Количество работы, выполненное за
единицу времени:
• MB/sec
• ops/sec, transactions/sec
• FPS frames per second
Время...
• ...работы
• Execution time: общее время исполнения
• ...отклика
• Latency: время отдельной операции
• Response time: задержка между стимулом и реакцией
• ...запуска
• Startup time: время до начала работы
• Time to performance: время до начала хорошей работы
Память

6. Представление метрик
“A в N раз быстрее B” означает
SpeedUp = ABS(Time(A) – Time(B)) / Time(B);

7. Как ускорить. Основные шаги
Что мешает работать быстрее?
– Делаем эксперименты и проверяем метрики на проблемных местах
Где это находиться?
– Делаем и проверяем предположение с помощью profiler tools
Как это исправить?
– Итеративный подход

8. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями

9. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями

10. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями

11. Система распределённых вычислений
Требования
– Workflow system

12. Система распределённых вычислений
Требования
Большой объем Read-Only data
Data read distribution
Read only HSQL MySQL Oracle
7%
17%
16% 60%

13. Архитектурные ЗА и ПРОТИВ
Кешируем RO
– Как распределять кеш между нодами?
– Как контролировать размер кеша?
– Как узнать на сколько эффективен кеш?
– Если через 5 секунд ситуация изменилась?
– Как организовать кеш локально?
Обрабатываем ивенты параллельно
– Сколько потоков создать?
– А если 2 потока начнут обработку одного
ивента?
– Как узнать на сколько эффективно
добавление еще одного потока?
– Если через 5 секунд ситуация изменилась?

14. Решения
Ранжируем данные в кеше по полезности
– Что полезнее закешировать таблицу Users или Books?
Измеряем производительность системы
– Какую взять метрику?
Используем данные измерений что бы изменить
критерии
– Стало лучше на 5%, это хорошо?
– Стало лучше в 3000 раз, WTF?
2 стратегии измерения
– Application-based
– System-based

15. System-based
Метрика - events/sec
Может лучше System.nanoTime();?
Какой будет overhead?
Что делать при параллельном исполнении?

16. Application-based
Метрика уже другая - выполненная работа
Overhead правда чуть выше
Параллельное исполнение - не проблема
Когда подход не будет работать?