Your SlideShare is downloading. ×
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Java Performance
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Java Performance

1,469

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,469
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 правда чуть вышеПараллельное исполнение - не проблемаКогда подход не будет работать?

×