Wydajne skalowanie aplikacji Java Enterprise

Transkrypt

Wydajne skalowanie aplikacji
Java Enterprise
Warszawa, 21 listopad 2011
Skalowanie aplikacij JEE
www.worlditsystems.com
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 Computng i okolice
Rozwiązywanie problemów z aplikacja
Slajd 3
Kiedy aplikacja działa
wolno?
Slajd 4
•
2 metody, które (już nie) działają
–
–
•
Jak sobie radzić z
problemami z wydajnością
aplikacji?
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
–
•
Przyczyna
–
•
“Hitng the Memory Wall: Implicatons of the
Obvious” - Wm. A. Wolf, Sally A. McKey, Computer
Science Report No. CS-94-48, December 1994
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
Czas
odpowiedzi P ercentyl
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%
Slajd 7
>2
100,00%
Co poszło nie tak?
•
Czasy odpowiedzi
–
Średnia – 0,75 sek
–
Mediana – 0,4 sek
Zachowanie systemu
•
Policzmy…
Czas odpowiedzi
1
120
•
–
–
Przez 60 minut, 100 wątków wykonywało
transakcję po 120 sekund
60/2*100  3000 transakcji
0
–
60
120
Czas
odpowiedzi
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
1,2
1,3
1,4
1,5
1,6
1,7
1,8
1,9
2
>2
czas
180
Przez pierwsze 120 minut, 100 wątków
Slajd 8
L iczba
próbek
125000
175000
200000
300000
250000
200000
150000
100000
75000
75000
50000
25000
25000
25000
22000
0
0
0
0
0
3000
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ą weryfkację kontraktów API
Slajd 9
•
O czym należy zapomnieć
–
–
–
•
Wstęp od Domain Driven
Architecture
Projektowanie botom-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
Domain Driven Design
API
–
–
•
SERVICES
EJB
SPRING
POJO
API
SEAM
Kod aplikacji
INTERFACES
SERVICES
Persystencja
–
–
•
Interfejsy obiektów
Interfejsy usług
Seam
Implementacja
–
•
GWT
Mapowania
Queries
„Spinacz”
–
Wystawia domenę na
DOMENA
•
GUI
JSF
Wicket
Repository
IMPLEMENTATION
Legacy
HERE BE DRAGONS
PERSISTENCE
Hibernate
JPA
Slajd 11
•
Rekomendowane
–
–
–
–
–
–
•
Wzorce projektowe i
frameworki
Domain Object (DO)
Data Transfer Object (DTO)
DTO Assembler
Repository
Generic DAO
Command
Nierekomendowane
–
–
Anemic domain objects
Repettve DAO
Slajd 12
Trochę przykładów
Domena 1
•
•
Jakie domeny można
wydzielić?
Mapowanie obiektów
–
–
•
Ile tabel zrobić?
Pliki XML czy anotacje?
Person
Domena 2
Company
Employee
Address
Room
City
Repozytoria
–
RoomRepository
•
•
–
getAllRooms(Company)
fndEmployeeRoom(Employee)
EmployeeRepository
•
Slajd 13
Duże projekty w DDD
•
Pamiętaj
–
–
–
–
•
GUI 1
GUI 2
SERWISY
Serwis 1
Serwis 2
DOMENY
Domena 1
Domena 2
Możliwość wymiany
Domena 3
Domena 4
Elementu domeny
Całej domeny
Domena 5
Domena 6
–
–
•
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  )
GUI
Slajd 14
Jak to wszystko podzielić?
•
Typowe problemy i
rozwiązania
–
Relacje dwukierunkowe
•
–
Zależności między obiektami
•
•
•
–
 Relacja jednokierunkowa i
repozytorium
 Używanie Mock’ów
 Enkapsulacja logiki
wewnątrz domeny
 Zaślepianie zależności
Transakcje pomiędzy
domenami
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
Slajd 16
Najsłabsze ogniwo… klient 
•
Wymagania zawsze będą się zmieniać
–
•
Pracuj z klientem na prototypach
–
–
•
Przeważnie można to przewidzieć
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
Tuning,
monitoring i
konfguracja
Narzędzia do
optymalizacji
Przykładowe
Produkty
Aplikacji
Applicaton Performance
Monitoring
CA Wily,
dynaTrace,
JenniferSof
Framework
Serwera aplikacji
Infrastructure Monitoring
IBM Tivoli, HP
OpenView
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 tme Optmizaton
MoreVRP
Sprzęt
Rozbudowa
sprzętu
Hardware Monitoring
HP SIM, IBM
Director
Architektura
rozwiązania
Infrastruktura
Aplikacja
Obiekty
Serwer aplikacyjny
DB
DB
CPU
DB
DB
I/O
Slajd 18
Jak rozwiązywać problemy
•
•
•
Testy wydajnościowe powinny zidentyfkować
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 - defnicje
•
Compute Grid
–
•
Data Grid
–
•
Compute Grid + Data Grid
Cloud
–
•
Równoległy i rozproszony storage
Grid Computng
–
•
Równoległe i rozproszone przetwarzanie
Zestaw API dostarczający „pewną” funkcjonalność
Cloud Computng
–
Datacenter + API (Cloud)
Slajd 20
•
Data Grid
–
–
•
Terracota (Sofware AG)
Oracle Coherence
Grid Computng
–
–
•
Grid Computng rozwiązania
GridGain
JBOSS Infnispan
Cloud Computng
–
–
–
Amazon EC2
Google AppEngine
Microsof Azure
Slajd 21
•
Amazon oferuje
–
–
–
–
–
–
•
Cloud na przykładzie
Amazon EC2
Infrastrukturę dla aplikacji
Bazy danych
Kolejki
Storage
Dedykowane obrazy
…. I wiele więcej
Możliwe wykorzystanie
–
–
Skalowane środowisko
produkcyjne
Simple
Queue
Service
(SQS)
Simple DB
Elastc Compute Cloud
(EC2)
Simple
Storage
Service (S3)
Elastc Block
Store (EBS)
CloudFront
Slajd 22
Wykorzystanie Grid
Computng
•
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
•
–
Frameworki do przetwarzania
•
•
•
Przeważnie dostępne jako java.utl.Map
MapReduce
Job Scheduler
Persystencja
Slajd 23
•
Natywne narzędzia JDK
–
–
–
–
•
–
•
JVisualVM (wcześniej JConsole)
Jstat
Jmap
Jinfo…
Logi Garbage Collectora
–
•
A co jeżeli jednak musimy
znaleźć problem?
-Xloggc:<PLIK>
GCViewer (htp://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
What compacton?
Compacton?
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)
Slajd 27
Tuning GC
•
Opcja nr 2
Opcja nr 1
–
•
-XX:+UseSerialGC
-XX:
+UseConcMarkSweepG
C
•
•
•
•
XX:ParallelGCThreads=2
0
-XX:+UseParNewGC
-XX:SurvivorRato=8
XX:TargetSurvivorRato=
•
Usprawnienia
zwiększające
przepustowość
•
Duże rozmiary
sterty
•
Do 500 GB na
JVM/instancja
aplikacji
64 bitowa
architektura JVM
•
Możliwośc
Slajd 28
Skończona ilość dolarów 
–
Nieskończona liczba roboczogodzin 
Tryby pracy GC
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

Wydajne skalowanie aplikacji Java Enterprise

Transkrypt

Podobne dokumenty

Rozdział 3 – Fabryka: duża kuchnia Slajd 1

1. Wprowadzenie do problemów jakości energii elektrycznej (JEE) w