Wydajne skalowanie aplikacji Java Enterprise Warszawa, 21 listopad 2011
Cele prezentacji Zwiększenie świadomości dotyczącej jakości aplikacji Łatwiejsze określenie potencjalnych problemów z wydajnością/jakością Możliwość przewidzenia problemów przed ich wystąpieniem Możliwość wykorzystania sprawdzonych rozwiązań Slajd 2
Agenda Jak monitorować aplikację Po co nam testy? Domain Driven Development Interakcja z klientem Skalowanie komponentów aplikacyjnych Cloud Computing i okolice Rozwiązywanie problemów z aplikacja Slajd 3
Kiedy aplikacja działa wolno? Slajd 4
Jak sobie radzić z problemami z wydajnością aplikacji? 2 metody, które (już nie) działają BHW Buy HardWare BMHW Buy More HardWare Historia rozwoju CPU CISC Częstotliwość Wielordzeniowość Teraz trzeba pisać lepsze aplikacje Slajd 5
Memory Wall Problem przewidziany w połowie lat 90 Hitting the Memory Wall: Implications of the Obvious - Wm. A. Wolf, Sally A. McKey, Computer Science Report No. CS-94-48, December 1994 Przyczyna Częstotliwość i moc procesorów rozwija się szybciej niż przepustowość i latency pamięci Efekt dobre lata 90 aplikacja wykorzystuje ok. 50% RAM XXI wiek aplikacja wykorzystuje ok. 10% RAM Slajd 6
Testy, testy, testy Wymagania niefunkcjonalne dotyczące testów Czas trwania: 180 min Dodatkowo 60 minut na warm-up Liczba równoległych użytkowników: 100 Średni czas odpowiedzi: < 1 sek 99 percentyl: < 2 sek Czas odpowiedzi Percentyl 0,1 6,94% 0,2 16,67% 0,3 27,78% 0,4 44,44% 0,5 58,33% 0,6 69,44% 0,7 77,78% 0,8 83,33% 0,9 87,50% 1 91,67% 1,1 94,44% 1,2 95,83% 1,3 97,22% 1,4 98,61% 1,5 99,83% 1,6 99,83% 1,7 99,83% 1,8 99,83% 1,9 99,83% 2 99,83% >2 100,00% Slajd 7
Czas odpowiedzi 1 120 Skalowanie aplikacij JEE Co poszło nie tak? Czasy odpowiedzi Średnia 0,75 sek Mediana 0,4 sek Zachowanie systemu Policzmy Przez 60 minut, 100 wątków wykonywało transakcję po 120 sekund 60/2*100 3000 transakcji Przez pierwsze 120 minut, 100 wątków wykonało 1 797 000 transakcji 3000 to 0,17% wszystkich transakcji! A system przez 60 minut nie działał! Czas odpowiedzi Liczba próbek 0,1 125000 0,2 175000 0,3 200000 0,4 300000 0,5 250000 0,6 200000 0,7 150000 0,8 100000 0,9 75000 1 75000 1,1 50000 1,2 25000 1,3 25000 1,4 25000 1,5 22000 1,6 0 1,7 0 1,8 0 1,9 0 2 0 >2 3000 0 60 120 180 czas Slajd 8
Test Driven Development Ankieta Ilu z Was robi testy jednostkowe? Jaki procent kodu pokryty jest testami 90% 75% 50% Ilu z Was robi automatyczne testy GUI? Ilu z Was używa ciągłej integracji? Po co nam testy? Umożliwiają wykrycie błędów Umożliwiają weryfikację kontraktów API Zapewniają, że mamy (większą) pewność, że nasz kod działa poprawnie Ratują nam życie przy zmianach!!! Slajd 9
Wstęp od Domain Driven Architecture O czym należy zapomnieć Projektowanie bottom-up zaczynając od modelu bazy danych Umieszczanie logiki w oddzielnej warstwie (EJB) Tworzenie prostych obiektów POJO O czym należy jednak pamiętać W końcu i tak użyjemy bazy danych Wykorzystujmy jak najwięcej wzorców projektowych Testy, testy, testy Slajd 10
DOMENA Domain Driven Design API Interfejsy obiektów Interfejsy usług Implementacja Kod aplikacji Persystencja Mapowania Queries Spinacz Wystawia domenę na świat Integruje systemy zewnętrzne Serwisy Warstwa dostępowa z GUI Zawiera obiekty DTO GUI Warstwa prezentacji GUI GWT JSF Wicket Seam SERVICES SPRING EJB POJO API INTERFACES IMPLEMENTATION HERE BE DRAGONS Hibernate PERSISTENCE JPA SEAM SERVICES Repository Legacy Slajd 11
Wzorce projektowe i frameworki Rekomendowane Domain Object (DO) Data Transfer Object (DTO) DTO Assembler Repository Generic DAO Command Nierekomendowane Anemic domain objects Repetitive DAO Fat Service Layer Feature Envy Frameworki Proste Dobrze udokumentowane Niekoniecznie wszystko-umiejące Slajd 12
Trochę przykładów Jakie domeny można wydzielić? Mapowanie obiektów Ile tabel zrobić? Pliki XML czy anotacje? Repozytoria RoomRepository getallrooms(company) findemployeeroom(employee) EmployeeRepository getallemployees(room) Domena 2 Company Room Domena 1 Person Employee Address City Slajd 13
Duże projekty w DDD Pamiętaj Odpowiednio podziel API Wypracuj stabilne API na początku projektu Rób częste iteracje Rób tyle testów ile się da (trust no one ) Możliwość wymiany Elementu domeny Całej domeny Im więcej domen tym bardziej przypomina to SOA GUI GUI 1 GUI 2 SERWISY Serwis 1 Serwis 2 DOMENY Domena 1 Domena 2 Domena 3 Domena 4 Domena 5 Domena 6 Slajd 14
Jak to wszystko podzielić? Typowe problemy i rozwiązania Relacje dwukierunkowe Relacja jednokierunkowa i repozytorium Zależności między obiektami Używanie Mock ów Enkapsulacja logiki wewnątrz domeny Zaślepianie zależności Transakcje pomiędzy domenami olać Transakcje rozproszone Bounded Context Cykl życia obiektów Zaślepianie zależności Wydzielanie komponentów aplikacyjnych Slajd 15
Wpływ błędów w zależności od warstwy API Bardzo bolesne i pracochłonne Analogiczny problem jak zły projekt w modelu wodospadowym Jak minimalizować skutki Upewnij się, że jest dobra komunikacja z klientem Tworzyć testy jednostkowe w innych warstwach Implementacja Relatywnie łatwe do wykrycia i naprawienia Jak minimalizować skutki Testy, testy, testy Persystencja Może generować dziwne dane biznesowe (przy błędnym mapowaniu) Jak minimalizować skutki Testy sprawdzające czy wszystkie dane się zapisały Spinacz Błędy widoczne na zewnątrz aplikacji Często mogą wynikać z błędów w innych warstwach Jak minimalizować skutki Tworzenie testów przed implementacją i persystencją Serwisy Powinny być w miarę proste i związane z mapowaniem obiektów domeny na DTO Często wykrywane na poziomie GUI Jak minimalizować skutki Testy, testy, testy Slajd 16
Najsłabsze ogniwo klient Wymagania zawsze będą się zmieniać Przeważnie można to przewidzieć Pracuj z klientem na prototypach Wizualnych Programistycznych Rób częste iteracje (2-4 tygodnie) Szybko odkryjesz nieścisłości Wymusisz dostarczanie deliverables Klient będzie miał wrażenie, że coś się dzieje Slajd 17
Gdzie szukać problemów Architektura rozwiązania Infrastruktura Tuning, monitoring i konfiguracja Aplikacja Obiekty Aplikacji Narzędzia do optymalizacji Application Performance Monitoring Przykładowe Produkty CA Wily, dynatrace, JenniferSoft Serwer aplikacyjny Framework Serwera aplikacji Infrastructure Monitoring IBM Tivoli, HP OpenView DB DB DB DB SQL DML Zapytań SQL, indeksów Database Performance Monitoring Quest DBMS SQL DDL, DCL Serwera bazy danych Database Monitoring Oracle Resource Manager System operacyjny Procesy, zasoby Systemu operacyjnego Real time Optimization MoreVRP CPU I/O Sprzęt Rozbudowa sprzętu Hardware Monitoring HP SIM, IBM Director Slajd 18
Jak rozwiązywać problemy Testy wydajnościowe powinny zidentyfikować ok. 75% problemów przed wdrożeniem Dodanie warstwy cache powinno być możliwe na każdym poziomie Implementacja nie powinna zależeć od technologii Slajd 19
Cloud i Grid - definicje Compute Grid Równoległe i rozproszone przetwarzanie Data Grid Równoległy i rozproszony storage Grid Computing Compute Grid + Data Grid Cloud Zestaw API dostarczający pewną funkcjonalność Cloud Computing Datacenter + API (Cloud) Slajd 20
Grid Computing - rozwiązania Data Grid Terracota (Software AG) Oracle Coherence Grid Computing GridGain JBOSS Infinispan Cloud Computing Amazon EC2 Google AppEngine Microsoft Azure Slajd 21
Cloud na przykładzie Amazon EC2 Amazon oferuje Infrastrukturę dla aplikacji Bazy danych Kolejki Storage Dedykowane obrazy. I wiele więcej Możliwe wykorzystanie Skalowane środowisko produkcyjne Serwer FTP Storage dla danych (zdjęcia) Backup Środowisko testowe Simple Queue Service (SQS) Simple DB Elastic Compute Cloud (EC2) Simple Storage Service (S3) CloudFront Elastic Block Store (EBS) Slajd 22
Wykorzystanie Grid Computing GUI Przechowywanie sesji użytkownika Przechowywanie obiektów współdzielonych Implementacja Duże obszary danych dla obiektów (100+GB) Niezawodne i koherentne kontenery danych Przeważnie dostępne jako java.util.map Frameworki do przetwarzania MapReduce Job Scheduler Persystencja Cache 2 poziomu Data storage zamiast typowej bazy danych Slajd 23
A co jeżeli jednak musimy znaleźć problem? Natywne narzędzia JDK JVisualVM (wcześniej JConsole) Jstat Jmap Jinfo Logi Garbage Collectora -Xloggc:<PLIK> GCViewer (http://www.tagtraum.com/) Memory Analyzer (Eclipse) Sporo komercyjnych rozwiązań Slajd 24
Narzędzia do diagnozy problemów Slajd 25
Garbage Collector Obiekty alokowane są w przestrzeni young Jeżeli przetrwają X czasu są przenoszone do obszaru survivor Często są 2 równoległe procesy GC Young przeważnie nie powodujący przestoju aplikacji Old przeważnie powodujący przestój aplikacji Pamięć ulega fragmentacji Wszystkie GC (poza Azul Systems) zatrzymują aplikację (stop-theworld) w czasie fazy kompaktowania (defragmentacja) What compaction? Compaction? Slajd 26
Garbage Collector tryby pracy Sposoby działania GC Serial Collector Gdy brak wymagań na małe przestoje Dobry jako client side Używa tylko 1 rdzenia Parrallel Collector Maksymalizuje przepustowość Nadal wstrzymuje aplikację Nie gwarantuje krótkich pauz Dobry dla batch processing Mostly-Concurrent Collector Minimalizuje latency (przestoje) Young generation analogicznie do poprzednich Old generation przetwarza równolegle i zatrzymuje aplikację na 2 fazy z 3 Wszystkie GC mają problem z kompaktowaniem pamięci! Slajd 27
Tuning GC Opcja nr 1 Opcja nr 2 Tryby pracy GC -XX:+UseSerialGC -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=20 -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 (default 50) -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC -XX:ParallelGCThreads=20 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:MaxGCPauseMillis=<X> -XX:GCPauseIntervalMillis=<X> Inne ustawienia GC -XX:+DisableExplicitGC -Xloggc:<file> -verbose:gc Ustawienia rozmiaru pamięci -Xms<SIZE><m g> -Xmx<SIZE><m g> -Xmn<SIZE><m g> Inne ustawienia JVM -Xss<SIZE>k -XX:+UseLargePages -XX:LargePageSizeInBytes=<SIZE>m (default 4m) -XX:ReservedCodeCacheSize=<SIZE>m (default 32m) -XX:MaxPermSize=<SIZE> (default 64m) -XX:+AggressiveOpts Nieskończona liczba roboczogodzin Usprawnienia zwiększające przepustowość Duże rozmiary sterty Do 500 GB na JVM/instancja aplikacji 64 bitowa architektura JVM Możliwośc wykorzystania 32 bitowe proxy z 64 bitowymi rozmiarami pamięci Wsparcie dla 64 bitowych środowisk Wspierane sprzętowo odśmiecanie (Garbage Collecting) Równoległe, jednoczesne, ciągłe Wspierane sprzętowo optymistyczne blokowanie Optymistyczne wykonywanie wątków umożliwia dużą skalowalność Kompaktowanie realizowane równolegle z aplikacją Skończona ilośd dolarów Slajd 28
Find a bug Klient mówi Wszyscy użytkownicy muszą długo czekać na odpowiedź Wykorzystanie CPU na maszynach jest na poziomie 10% Developer mówi U mnie się skaluje rewelacyjnie Przy testach obciążenie CPU jest >75% Slajd 29
Dziękuję Slajd 30