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: время до начала хорошей работы
Память
7. Как ускорить. Основные шаги
Что мешает работать быстрее?
– Делаем эксперименты и проверяем метрики на проблемных местах
Где это находиться?
– Делаем и проверяем предположение с помощью profiler tools
Как это исправить?
– Итеративный подход
8. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями
9. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями
10. Что можно улучшить
Уровень системы
– I/O (Сеть/Диск)
– Операционная система
– Процессор/память
Уровень JVM
– Издержки работы самой JVM
– Время GC
Уровень приложения
– Количество потоков (мало или даже много)
– Лишние блокировки, синхронизация
– Алгоритмические проблемы (лишние вызовы, неэффективные структуры
данных и алгоритмы)
Архитектурный уровень
– Кеширование
– Распределение нагрузки на нескольких узлов
– Оптимизация взаимодействия между слоями
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
16. Application-based
Метрика уже другая - выполненная работа
Overhead правда чуть выше
Параллельное исполнение - не проблема
Когда подход не будет работать?