Monitorowanie i badanie wydajności aplikacji biznesowych bazujących na technologii Java EE

Źródło problemu Plan prezentacji Technologia Java EE Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

Źródło problemu System zapisów na egzaminy Wymogi projektowe: Ograniczony dostęp do zasobów CK Wymogi projektowe: JSF/Facelets WebServices (WS) JDBC Zapis informacji o działaniu aplikacji do dziennika zdarzeń Problemy: Wpływ zapisu informacji na pracę aplikacji Powtórzenia kodu

Powtórzenia kodu Uzyskanie/zwolnienie połączenia bazodanowego Zwolnienie przygotowanych zapytań (ang. prepared statements) Obsługa wyjątków Zapis komunikatów do dzienników zdarzeń o: Rozpoczęciu/zakończeniu działania metody WS Rozpoczęciu/zakończeniu działania metod aplikacji JSF Rzuconym wyjątku

Technologia Java EE Plan prezentacji Źródło problemu Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

Ważniejsze technologie Java EE Java EE nie jest jednolitą specyfikacją. Jest raczej zbiorem technologii, które ze sobą współpracują: Serwlety i JSP/JSF (Kontener WEB) Enterprise Java Beans (Kontener EJB) JMS (Java Message Service) Contexts and Dependency Injection (JSR 299) JAX-WS i XML JTA (Java Transaction API) JPA (Java Persisence API) JCA (Java Connector Architecture)

Ważniejsze technologie Java EE JEE WEB EJB JMS JAX-WS XML JPA/JTA JCA JSR 299 Contexts and Dependency Injection

Java EE – zarządzanie i monitorowanie Aplikacje Serwer aplikacji Java EE MBeans MxBeans Java Management eXtensions JVM System operacyjny Logger (java.util.Logger, log4j) MBeans, MxBeans i Java Management eXtensions Interceptory dla komponentów EJB Filtry dla serwletów ActionListener-y dla JSP/JSF Aspekty: AspectJ modyfikacja kodu (ASM) Sprzęt

Java EE – zarządzanie i monitorowanie Aplikacje Serwer aplikacji Java EE Logger (java.util.Logger, log4j) Narzędzie serwera aplikacyjnego Konsola administracyjna JVM System operacyjny Sprzęt

Java EE – zarządzanie i monitorowanie Logger (java.util.Logger, log4j) Interceptory dla komponentów EJB Filtry dla serwletów ActionListener-y dla JSP/JSF Metody cyklu życia komponentów Matody cyklu życia encji Dynamiczne proxy Modyfikacja kodu binarnego AspectJ ASM Aplikacje Serwer aplikacji Java EE JVM System operacyjny Sprzęt

Źródła problemów Błędy Błędy w kodzie serwera aplikacji Błędy konfiguracji serwera aplikacji Błędy w kodzie aplikacji Błędy konfiguracji aplikacji Nie są brane problemy związane z infrastrukturą sprzętową i dostępem do bazy danych Wiele problemów nie wynika z błędów w aplikacji, ale problemami konfiguracyjnymi. Np. zbyt mała pula połączeń do bazy danych W większości przypadków problem da się usunąć bez wyłączania aplikacji, poprzez prostą rekonfigurację serwera.

Monitorowanie aplikacji Java EE Plan prezentacji Źródło problemu Technologia Java EE Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

Logger Standardowy mechanizm pozwalający zapisywać komunikaty do dziennika zdarzeń Zalety: Poziomy - ograniczenie ilości informacji Możliwość konfiguracji, włączania i wyłączania w locie Wady: Wymagane jest umieszczenie wywołań Logger-a w kodzie, przeważnie w kilku miejscach Wpływa na wydajność działania aplikacji, nawet gdy jest wyłączony (test isLoggable). W przypadku konieczności zapisu dużej ilości informacji/konieczności jej wytworzenia wpływ może być nawet istotny

Logger – przykład public void usunTerminEgzaminu(Integer terminId) throws EgzaminyWyjatek { if (LOGGER.isLoggable(Level.FINER)) { LOGGER.entering(getClass().getName(), "usunTerminEgzaminu", terminId); } ... try { if (result == 0) { LOGGER.log(Level.SEVERE, "Nie udało się usunąć terminu egzaminu o id <" + terminId + ">"); throw new EgzaminyWyjatek(NIEUDANE_USUNIECIE_TERMINU); } catch (SQLException e) { obslugaSqlException(e); } finally { zwolnijPolaczenie(connection); LOGGER.exiting(getClass().getName(), "usunTerminEgzaminu");

JMX i MBeans Management Beans Standardowy mechanizm maszyny wirtualnej Java Instalacja MBeans podczas uruchamiania aplikacji Razem z aplikacją Osobno ( w przypadku kontenerów aplikacyjnych) Podobnie jak w przypadku logger-a, konieczne jest dodanie do kodu aplikacji instrukcji zapisujących informację w MBean-ach

JMX

JMX

JMX

MBean - przykład public class WsCounter implements WsCounterMBean{ private int counter=0; public int getWSCounter() { return counter; } public void incrementCounter() { counter++; public void resetCounter() { counter=0;;

MBean - przykład Uzyskaj dostęp do MBean Kiedy instalować MBean? ObjectName objectName =new ObjectName ("pl.performance:type=WsCounterMBean"); final MBeanServer platformMBeanServer = ManagementFactory.getPlatformMBeanServer(); mbean=(WsCounterMBean) MBeanServerInvocationHandler. newProxyInstance(platformMBeanServer, objectName, WsCounterMBean.class,false); Kiedy instalować MBean? Java EE 6 @Singleton – inicjalizacja parametrów dla aplikacji Synchronizacja dostępu do sesyjnych komponentów typu singleton

Interceptory EJB Narzędzie o największych możliwościach Pełny dostęp do komponentu poprzez refleksję: Pola Metody, argumenty i wartości przez nie zwracane Wyjątki Adnotacje Transakcje Wątek w którym komponent się znajduje (komponenty EJB nie mogą być współdzielone przez wątki) Implementowane poprzez: Dynamiczne proxy (Glassfish) Modyfikację kodu podczas ładowania (OpenEJB)

Interceptory EJB – przykład Mierzenie czasu wykonania metody Tworzenie przy pomocy adnotacji pułapek informujących o zbyt długim czasie wykonywania metody Nazywanie wątków. Domyślna nazwa nic nie mówi Ułatwia także proces debug-owania

Interceptory EJB – przykład Adnotacja @Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Threshold {public int time();} Komponent EJB @Stateless @Interceptors(ExecutionTime.class) public class BusinessComponent implements BusinessComponentRemote { @Threshold(time=5) public String monitoredMethod(String name) {...} @PostConstruct public void init(){...} }

Interceptory EJB – przykład public class ExecutionTime { @AroundInvoke Object measureExecutionTime(InvocationContext ic) throws Exception { long startTime = System.currentTimeMillis(); Method method = ic.getMethod(); try { return ic.proceed(); } finally { Threshold threshold = method.getAnnotation(Threshold.class); long endTime = System.currentTimeMillis() - startTime; if (threshold != null && endTime > threshold.time()) ... }

EJB Lifecycle Callback Event Handlers Lifecycle callback handlers: javax.annotation.PostConstruct javax.annotation.PreDestroy javax.ejb.PostActivate javax.ejb.PrePassivate Brak możliwości bezpośredniej komunikacji pomiędzy wywołaniami metod Komunikacja przez pola komponentu EJB

SFSB (Stateful Session Bean) javax.ejb.SessionSynchronization Rozszerzenie cyklu dla komponentów stanowych afterBegin beforeCompletion/afterCompletion(true) afterCompletion(false) Transakcji nie da się monitorować interceptorem z uwagi na to, że on sam stanowi cześć transakcji.

JPA Lifecycle Callback Event Handlers @javax.persistence.PrePersist @javax.persistence.PostPersist @javax.persistence.PostLoad @javax.persistence.PreUpdate @javax.persistence.PostUpdate @javax.persistence.PreRemove @javax.persistence.PostRemove

JPA Lifecycle Callback Event Handlers Nie istnieje Object obj=new Object() Usunięcie w DB @PostRemove Nowy EntityManager.persist(obj) @PrePersist insert @PostPersist EntityManager.remove(obj) @PreRemove Rozpoczęcie usuwania w DB Odłączony Zarządzany Usunięty @PreUpdate update @PostUpdate EntityManager.refresh(obj) @PostLoad

Tube 1 Tube 2 Tube 3 Interceptory dla WS Zależne od implementacji JAX-WS Dla JAX-WS „Metro” jest to tzw. „tubeline assembler” Typowy interceptor Serwer aplikacji Tube 1 Tube 2 Tube 3 Klienci WS Żądanie/Odpowiedź SOAP

Filtry i ActionListenery Typowy interceptor @Override public void processAction(ActionEvent arg0) throws AbortProcessingException { try { ... super.processAction(arg0); } catch (Exception e) { LOGGER.log(Level.SEVERE, "WYJĄTEK APLIKACJI WEB", e); }

Skoro jest tak dobrze, to dlaczego jest źle?

Problem i cel Brak jednolitego mechanizmu pozwalającego monitorować aspekty działania aplikacji biznesowej w technologii Java EE Stworzenie mechanizmu działającego z każdym typem komponentów technologii Java EE

Cechy poszukiwanego rozwiązania Możliwość monitorowania (nawet zdalnego) działania aplikacji Kod monitorujący nie powinien być częścią kodu logiki aplikacji Instalacja razem z logiką aplikacji Możliwość (zdalnego) włączania/wyłączania monitorowania aplikacji, bez konieczności jej przebudowy/przeładowania Podczas budowy aplikacji kod monitorujący powinien podlegać testom !!! Określenie obiektu monitorowania Przeładowanie – dotyczy np. usunięcia z konfiguracji aplikacji interceptorów i ponowne załadowanie aplikacji. Zamieniana jest tylko więc konfiguracja, źródła nie są ponownie kompilowane Splatanie kodu podczas ładowania klas niestety nie pozwala na testowanie. Jak działa aplikacja, jesteśmy w stanie się przekonać dopiero po uruchomieniu aplikacji

Rozwiązania istniejące Glassbox Zestaw narzędziowy rozpoznający popularne framework-i Osobna aplikacji instalowana na serwerze aplikacyjnym AspectJ JBoss AOP Modyfikacja łańcucha interceptorów (Javassist) Pracuje jako samodzielny kontener lub jako część JBossAS

Proces W działającej aplikacji pojawia się problem, np.: Nieprawidłowe działanie Mała wydajność Zbyt duża zajętość zasobów Trwale zablokowane wątki Włączany jest system monitorujący pracę aplikacji (bez jej wyłączania – wymóg biznesowy), inaczej: Konieczność projektowania systemu pod względem zapamiętywania stanu podczas wyłączania Klastry Analiza komunikatów Naprawienie błędów

Proces Nieprawidłowe działanie Mała wydajność Zbyt duża zajętość zasobów Trwale zablokowane wątki

Architektura Agent JMX MBeans Konsola JMX Komponenty narzędziowe Ładowany podczas uruchomienia maszyny wirtualnej MBeans Instalowane podczas instalacji aplikacji wraz z komponentami narzędziowymi Konsola JMX Komponenty narzędziowe Podsystem składowania komunikatów

Architektura i Projekt Jednostka instalacyjna Narzędzia Aplikacja JMS, JDBC, Mail Serwer aplikacyjny JVM JMX/JConsole Agent JMX MBeans

Tryb normalny pracy aplikacji Jednostka instalacyjna Klienci Narzędzia Aplikacja JMS, JDBC, Mail JVM JMX/JConsole Agent JMX MBeans

Włączenie monitorowania – Splatanie kodu Podczas: Kompilacji (Compile–time) Ładowania klas (Class loading–time) Działania (Run–time) Uruchomienie narzędzia monitorującego powoduje wplecenie kodu narzędziowego w kod aplikacji Punkty splatania identyfikowane są poprzez adnotacje

Tryb monitorowania pracy aplikacji Jednostka instalacyjna Klienci Aplikacja JMS, JDBC, Mail Narzędzia JVM JMX/JConsole Agent JMX MBeans

Przyszłość – Java EE6 i JSR299 JBoss Seam (WebBeans) JSR 299 - Contexts and Dependency Injection Dekoratory Interceptory Zatarcie różnicy pomiędzy komponentem EJB a dowolnym innym bean-em zarządzanym, np. JSF Managed Beans

Podsumowanie Monitorowanie selektywne Możliwość „wyłączenia” kodu monitorującego podczas normalnej pracy Szybsze działanie aplikacji Zmniejszenie zajętości zasobów Szybsze wywołanie kodu narzędziowego od techniki interceptorów EJB3 Możliwość monitorowania dowolnego obiektu należącego do aplikacji

Czas na dyskusję i dziękuję za uwagę

Do sprawdzenia Hierarchia ładowania klas może stanowić problem. Dynamiczne proxy do przechwytywania wywołań APM – Application Perfomance Management W przypadku klastrowanych aplikacji przeładowanie aplikacji na węźle może nastąpić bez utraty dostępu do usług (ale trzeba to zrobić na wszystkich węzłach po kolei).