Java Performance
Download as PPTX, PDF1 like856 views
Документ содержит рекомендации по улучшению производительности Java-приложений, акцентируя внимание на выборе и проверке метрик, таких как время исполнения и задержка. Обсуждаются основные шаги для выявления и устранения проблем в разных уровнях системы, включая I/O, JVM и уровень приложения. Также рассматриваются подходы к кешированию и параллельной обработке данных в распределённых вычислительных системах.
Java Performance
- 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 правда чуть выше Параллельное исполнение - не проблема Когда подход не будет работать?