Sławomir Pawlikowski (Slawomir.Pawlikowski@pl.ibm.com)

Sławomir Pawlikowski (Slawomir.Pawlikowski@pl.ibm.com) Pomiary wydajności aplikacji dla WebSphere Process Server z użyciem narzędzia Request Metrics Narzędzie Request Metrics (Metryki żądań), wprowadzone w produkcie WebSphere Application Server V6, może pomóc zarówno w monitorowaniu wydajności aplikacji tworzonych dla WebSphere Process Server, jak i w śledzeniu indywidualnych transakcji w tych aplikacjach z rejestracją czasów przetwarzania danych w wybranych komponentach Serwera Procesów. Narzędzie pozwala na zilustrowanie szczegółowego przebiegu kompletnej transakcji, zazwyczaj silnie uzależnionego od danych zawartych w żądaniu przesyłanym do aplikacji środowiska Serwera Procesów. W przypadku złożonych rozwiązań dla WebSphere Process Server, zawierających zazwyczaj wiele komponentów wielokrotnie wykorzystywanych, tego typu funkcjonalność oprogramowania Request Metrics jest szczególnie użyteczna, ponieważ często nie jest możliwe określenie przebiegu transakcji jedynie w oparciu o statystyki Infrastruktury Monitorowania Wydajności (PMI) bez szczegółowej znajomości wewnętrznej architektury aplikacji. Jednak rekordy Request Metrics zapisywane w plikach dziennika SystemOut mają swój specyficzny format, co znacznie utrudnia zadanie ich bezpośredniej analizy. W artykule przedstawiono wypróbowaną metodykę przetwarzania i analizy rekordów Request Metrics, która wykorzystuje proste standardowe systemowe zlecenia związane z wyszukiwaniem tekstu oraz dedykowaną aplikację Java do wizualizacji przebiegu aplikacji z użyciem klasy Swing JTree. Page 1 of 26

Wprowadzenie Narzędzie Metryki Żądań (Request Metrics dalej w skrócie RM) zostało wprowadzone do produktu WebSphere Application Server (zwany dalej Serwerem Aplikacyjnym) w wersji 6 w celu monitorowania wydajności aplikacji poprzez śledzenie indywidualnych transakcji w oparciu o zapis czasu przetwarzania w wybranych komponentach Serwera Aplikacyjnego. Ponieważ produkt WebSphere Process Server (zwany dalej Serwerem Procesów) jest zbudowany na rdzeniu Serwera Aplikacyjnego, stąd też narzędzie RM może zostać wykorzystane zarówno do określania wydajności aplikacji Serwera Procesów, jak i do identyfikacji ich wąskich gardeł. W zestawieniu z Infrastrukturą Monitorowania Wydajności (Performance Monitoring Infrastructure dalej w skrócie PMI) Serwera Aplikacyjnego, narzędzie RM nie dostarcza wartości estymatorów związanych z wykorzystaniem zasobów systemowych, niemniej umożliwia zilustrowanie szczegółowego przebiegu kompletnej transakcji, zazwyczaj silnie uzależnionego od danych zawartych w żądaniu przesyłanym do aplikacji Serwera Procesów. Ta cecha RM jest szczególnie użyteczna w przypadku śledzenia złożonych rozwiązań dla Serwera Procesów, zawierających zazwyczaj wiele komponentów, które dodatkowo mogą być wykorzystywane w przebiegu transakcji wielokrotnie, bowiem w takiej sytuacji w zasadzie nie jest możliwe określenie przebiegu śledzonej transakcji jedynie w oparciu o statystyki PMI potrzebna jest szczegółowa znajomość wewnętrznej architektury takiego złożonego rozwiązania. Metryki Żądań w środowisku Serwera Procesów Jeśli oprzeć się o dobrze znany szablon architektoniczny zalecany dla projektów aplikacji zorientowanych usługowo (service-oriented architecture dalej w skrócie SOA), to przykładowe rozwiązanie dla Serwera Procesów w postaci złożonej aplikacji może składać się z kilku różnych komponentów (Rysunek 1). Rysunek 1. Przykładowa architektura złożonej aplikacji Serwera Procesów Page 2 of 26

BRules1_MOD Output1_MED BPEL1_MOD Input1_MED Output2_MED Output3_MED Input2_MED Output4_MED BPEL2_MOD Input mediation module with Web service export BPEL module Business Rules module Output mediation module with Web Service import Output mediation module interfacing Adapter module BRules2_MOD Output5_MED Pośród tych komponentów możemy wyróżnić: Wejściowe moduły mediacyjne (Input1_MED oraz Input2_MED na Rysunku 1), udostępniające aplikacyjne interfejsy komunikacyjne (ze względu na wykorzystywane i opisywane w tym artykule narzędzia ograniczamy się wyłącznie do eksportu typu Web Services (WS), chociaż można by przy użyciu innych narzędzi rozpatrywać również inne rodzaje eksportu, jak JMS, HTTP, itp.). Komponenty lub moduły procesów biznesowych (np. opartych o standard BPEL), zaprojektowane do realizacji zadanej części logiki biznesowej poprzez choreografię usług oraz przetwarzanie danych niesionych w obiektach biznesowych (moduły BPEL1_MOD oraz BPEL2_MOD na Rysunku 1). Komponenty lub moduły reguł biznesowych wykonujących kolejną część logiki aplikacyjnej poprzez elastyczne, zewnętrznie zarządzalne szablony reguł, zawierające parametryczne wartości modyfikowalne w czasie wykonania (moduły BRules1_MOD oraz BRules2_MOD na Rysunku 1). Wyjściowe moduły mediacyjne do komunikacji z usługami zewnętrznymi udostępnianymi przez istniejące systemy współpracujące (Output1_MED oraz Output2_MED na Rysunku 1). Wyjściowe moduły mediacyjne (moduły Output3_MED do Output5_MED na Rysunku 1) do komunikacji z modułami adapterów technologicznych (jak JDBC, plikowy, FTP oraz email) i adapterów aplikacyjnych (do współpracy z aplikacjami klasy ERP jak SAP, Siebel, PeopleSoft, itp.). Uwaga: Komponenty typu Human Task (Zadania manualne) nie są rozpatrywane powyżej ze względu na ich naturalną asynchroniczną naturę interakcji z użytkownikiem, której intensywność determinowałaby całkowitą wydajność rozpatrywanej aplikacji Serwera Procesów. Page 3 of 26

Jeśli wszystkie komponenty przedstawionego powyżej przykładowego rozwiązania dla Serwera Procesów będą pracować w ramach pojedynczej maszyny wirtualnej Java (Java Virtual Machine dalej w skrócie JVM) w środowisku uruchomieniowym Serwera Procesów z aktywnym podsystemem RM, to dla każdej transakcji zainicjowanej w tym środowisku narzędzie RM będzie tworzyć rekordy danych zawierające kluczowe informacje wiązane z przebiegiem danej transakcji. Między innymi będzie to czas trwania, spędzany w danym pojedynczym komponencie aplikacji podczas tej transakcji. W efekcie z użyciem danych korelacyjnych dołączanych do tych rekordów w trakcie przebiegu transakcji przez kolejne komponenty aplikacyjne Serwera Procesów zaangażowane w przetwarzanie, jest możliwe zbudowanie kompletnego obrazu śledzonej transakcji. Utworzone rekordy RM mogą być zapisywane w pliku dziennika systemowego SystemOut.log w celu późniejszej ich ekstrakcji i analizy lub też mogą być przesyłane do tzw. agentów podsystemu Pomiarów Odpowiedzi Aplikacji (Application Response Measurement - dalej w skrócie ARM), których zapewniają liczne zewnętrzne narzędzia (jak oprogramowanie z rodziny Tivoli Monitoring czy też Tivoli Composite Application Manager lub podobne). Narzędzia te zazwyczaj umożliwiają kompleksowe przetwarzanie danych RM i pełną wizualizację szczegółów przebiegu zarejestrowanych transakcji. Jednak najczęściej w projektach dla zewnętrznych klientów analiza RM jest przeprowadzana bezpośrednio w środowisku Serwera Procesów, a zatem zazwyczaj bez możliwości skorzystania z wymienionego typu narzędzi. Dlatego też głównym tematem tego artykułu jest zaprezentowanie techniki przetwarzania i analizowania rekordów RM przesyłanych do pliku dziennika systemowego, bowiem ze względu na specyficzny format danych tworzących rekordy RM nie jest to wcale łatwe zadanie. Rozpocznijmy od przyglądnięcia się przykładowemu wpisowi rekordu RM zapisanemu w pliku dziennika systemowego SystemOut.log Serwera Procesów, który przedstawiono i opisano na rysunku 2. Rysunek 2. Przykładowy wpis rekordu RM zapisany w pliku dziennika SystemOut.log Serwera Procesów Page 4 of 26

[6/18/09 13:21:03:916 BST] 0000008f PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=10.245.211.187,time=1245225131333,pid=569372,reqid=4196,event=1 current:ver=1,ip=10.245.211.187,time=1245225131333,pid=569372,reqid=4197,event=1 type=ejb detail=com.ibm.wsspi.sca.ejb.module.impl.modulesessionbean.transactionrequiredactivitysessionnotsupported elapsed=107 gdzie poszczególne sekcje wpisu oznaczają: [6/18/09 13:21:03:916 BST] TimeStamp (znacznik czasu) TimeStamp (znacznik czasu) jest sformatowany zgodnie z ustawieniami środowiska lokalnego, zawierając pełną kwalifikowaną datę (6/18/09 jako MM/DD/YY), 24-godzinny czas wraz z milisekundami oraz strefą czasu (jak w przykładzie - BST - British Summer Time) ThreadId (identyfikator wątku) 0000008f (identyfikator wątku) Ośmioznakowa wartość heksadecymalna wygenerowana z kodu skrótu (hash code) wątku, który opublikował zdarzenie PmiRmArmWrapp ShortName (skrócona nazwa) Skrót nazwy komponentu rejestrującego PMI RM I Message type (typ komunikatu): I for Info PMRM0003I: Message number (numer komunikatu): PMRM003I parent:ver=1,ip=10.245.211.187,time=1245225131333,pid=569372,reqid=4196,event=1 Łańcuch Parent Correlator (korelator nadrzędny) identyfikuje poprzedzający rekord RM; reprezentuje nadrzędne żądanie w obrębie tego samego wątku (format łańcucha opisany jest poniżej). current:ver=1,ip=10.245.211.187,time=1245225131333,pid=569372,reqid=4197,event=1 Łańcuch Current Correlator (korelator bieżący) identyfikuje dany (aktualny) rekord RM w obrębie tego samego wątku, czyli reprezentuje bieżącą operację. Ogólny format korelatora jest taki sam dla nadrzędnego i bieżącego korelatora: jest to łańcuch złożony z oddzielanych znakiem przecinka pól poprzedzanych określonym słowem kluczowym ( parent: lub current: ), w którym można wyróżnić następujące pola: ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn gdzie o o o o o o ver Wersja korelatora (powielona w nadrzędnym i w bieżącym korelatorze) ip Adres IP węzła serwera aplikacyjnego, który wygenerował ten korelator pid ID procesu serwera aplikacyjnego, który wygenerował ten korelator time Czas rozpoczęcia procesu serwera aplikacyjnego, który wygenerował ten korelator reqid ID przypisany przez RM żądaniu, unikatowy dla procesu serwera aplikacyjnego event ID zdarzenia przypisany w celu rozróżniania rzeczywistych zdarzeń type=ejb Kod następujący po słowie kluczowym type= reprezentuje typ mierzonej operacji; dla Serwera Procesów wspierane są następujące typy: URI, EJB, JDBC, Web Services Provider and Web Services Requestor, Servlet Filter, Asynchronous Bean, JNDI, JMS, SIB, JCA. detail=com.ibm.wsspi.sca.ejb.module.impl.modulesessionbean.transactionrequiredactivitysessionnotsupported Łańcuch następujący po słowie kluczowym detail= identyfikuje szczegółową nazwę mierzonej operacji elapsed=107 Wyznaczony dla danej operacji czas jej trwania w milisekundach; czas ten zawiera w sobie czasy trwania wszystkich kolejnych podrzędnych operacji wywoływanych przez tą operację Ważnym składnikiem prezentowanego powyżej wpisu rekordu RM jest sekcja korelacyjna, złożona z dwóch elementów zwanych korelatorami: korelatora nadrzędnego oraz korelatora bieżącego. Jeśli ich wartości są identyczne w danym rekordzie, to rekord ten odzwierciedla operację, która odbywa się bezpośrednio na wejściu do Serwera Procesów, co oznacza po prostu najwyższy nadrzędny poziom w przebiegu aplikacyjnym. Natomiast w celu wyznaczenia pozycji danego rekordu w przebiegu transakcji dla takich rekordów, w których wartości korelatorów nadrzędnego i bieżącego różnią się między sobą, należy przeprowadzić operację Page 5 of 26

dopasowania skorelowanych z nimi rekordów RM. To dopasowanie wykonuje się poprzez skonstruowanie logicznego powiązania pomiędzy korelatorami bieżącymi w nadrzędnych rekordach RM i korelatorami nadrzędnymi w rekordach potomnych. W ten sposób tworzy się logiczne drzewo, które reprezentuje postęp żądania podążającego przez środowisko wykonawcze Serwera Procesów. Jednak ponieważ podsystem PMI Serwera Procesów nie posiada bezpośredniego wsparcia dla sporządzania tej struktury, autor opracował praktyczną metodę wykorzystującą proste standardowe zlecenia systemowe związane z wyszukiwaniem tekstu oraz dedykowaną aplikację napisaną w języku Java. Podejście to zostało opisane w dalszej części tego artykułu. Konfigurowanie narzędzia Request Metrics Działanie podsystemu RM w Serwerze Procesów jest kontrolowane poprzez konsolę administracyjną (Integrated Solutions Console dalej w skrócie ISC) na dedykowanej narzędziu RM stronie WWW. Do rozpoczęcia pracy w zupełności wystarcza konfiguracja ogólna, jakkolwiek czasami przydaje się dodatkowa funkcjonalność związana z konfiguracją filtracji RM. Ogólna konfiguracja narzędzia Request Metrics Aby skonfigurować RM w środowisku wykonawczym Serwera Procesów, otwórz konsolę ISC w przeglądarce WWW i wykonaj następujące kroki: 1. W drzewie nawigacyjnym menu rozwiń Monitorowanie i strojenie (Monitoring and Tuning) patrz Rysunek 3. 2. Kliknij na opcję Pomiary żądań (Request Metrics). 3. Włącz RM poprzez zaznaczenie pola wyboru Przygotuj serwery na zbieranie pomiarów żądań (Prepare servers for request metrics collection). 4. Określ Komponenty do instrumentacji (Components to be instrumented) poprzez zaznaczenie opcji spośród poniższych: a. Brak (None) instrumentacja RM jest wyłączona. b. Wszystko (All) dane RM będą gromadzone dla wszystkich komponentów wylistowanych w okienku pod opcją Niestandardowy ( Custom ) patrz opis poniżej. c. Niestandardowy (Custom) specyfikuje zbiór komponentów, dla których instrumentacja RM jest włączona. Możesz wybrać dowolną kombinację z listy zamieszczonej w okienku poniżej spośród nastepujących typów komponentów: AsyncBeans, EJB, JCA, JDBC, JMS, JNDI, Portlet, SIB, Servlet, Servlet Filter oraz Web Services. 5. W kolejnym polu Poziom śledzenia ( Trace level ) wybierz z listy opcję określającą ilość zbieranych informacji: a. Brak (None): żadne dane nie będą zbierane (instrumentacja RM jest wyłączona). b. Przeskoki (Hops): zbieranie informacji o granicach procesów. Page 6 of 26

c. Debugowanie wydajności (Performance_debug): jak w poziomie Przeskoki ( Hops ) plus informacje o jednym dodatkowym, pierwszym poziomie wywołania serwletu wewnątrz procesu oraz komponentu Enterprise JavaBeans (EJB). d. Debugowanie (Debug): szczegółowe informacje wraz z czasami odpowiedzi dla wszystkich wywołań wewnątrz procesu. 6. W sekcji Docelowe miejsce pomiarów żądań ( Request Destination ) zaznacz gdzie mają być przesyłane dane RM: metrics a. Dzienniki standardowe (Standard Logs): rekordy RM będą zapisywane do pliku SystemOut.log. b. Agent ARM (Application Response Measurement (ARM) agent): RM będzie wykorzystywał istniejącą infrastrukturę ARM poprzez wywołania wyspecyfikowanego poniżej agenta ARM. Jeśli wybierzesz tą opcję, powinieneś również podać dwa dodatkowe parametry: i. Typ agenta (Agent Type): wybierz spośród ARM40 oraz TIVOLI_ARM. ii. Nazwa klasy implementacji fabryki transakcji ARM (ARM transaction factory implementation class name): wartość wymagana jedynie, gdy wybierzesz powyżej opcję ARM40 wprowadź nazwę tej klasy dokładnie tak, jak jest określona w bibliotece użytkowej ARM. Uwaga: Przed uaktywnieniem infrastruktury ARM dla instrumentacji RM, musisz zainstalować agenta ARM oraz skonfigurować go z właściwymi wartościami ścieżek systemowych (path) oraz ścieżek do klas (classpath) zgodnie z instrukcją dostarczoną przez dostawcę ARM. 7. Zatwierdź swoje ustawienia konfiguracyjne klikając przycisk Zastosuj (Apply). Rysunek 3. Strona Web do konfiguracji Pomiarów żądań (Request Metrics) w konsoli administracyjnej Serwera Procesów. Page 7 of 26

Typowe ustawienia konfiguracyjne dla pomiarów wydajności aplikacji Serwera Procesów są następujące (patrz Rysunek 3): Zaznaczone pole wyboru Przygotuj serwery na zbieranie pomiarów żądań (Prepare servers for request metrics collection). Opcja Komponenty do instrumentacji (Components to be instrumented) ustawiona na Wszystko (All). W polu Poziom śledzenia (Trace level) wybrana opcja Debugowanie (Debug). W sekcji Docelowe miejsce pomiarów żądań (Request metrics Destination) zaznaczone pole wyboru Dzienniki standardowe (Standard Logs) oraz niezaznaczone pole Agent ARM (Application Response Measurement (ARM) agent). Powyższe wartości ustawień konfiguracyjnych są używane w przykładach pomiarów RM prezentowanych dalej w artykule. Opcjonalna konfiguracja Request Metrics filtracja W przypadku badania niektórych specyficznych problemów wydajnościowych jest potrzebna głębsza i bardziej szczegółowa analiza ograniczona jedynie do niektórych elementów śledzonej aplikacji. W takiej sytuacji możesz skorzystać z oferowanego przez narzędzie RM dodatkowego mechanizmu filtracji. Jeśli jest on włączony, dane pomiarów żądań będą generowane jedynie dla tych przychodzących zapytań, które Page 8 of 26

spełniają określone kryteria filtrowania. Gdy jest aktywnych naraz kilka wartości filtrów RM, dane żądanie będzie przepuszczane, o ile jest pasuje przynajmniej do jednej wartości. Aby określić, które filtry mają być śledzone, przejdź do strony filtrów RM poprzez łącze Filtry (Filters) pod opcją Właściwości dodatkowe (Additional Properties) i skonfiguruj filtrowanie dla dowolnie wybranej kategorii spośród pięciu predefiniowanych: EJB, JMS, SOURCE IP, URI oraz USŁUGI_WWW (WEB_SERVICES) - patrz Rysunek 4. Rysunek 4. Filtracja Request Metrics w konsoli administracyjnej Serwera Procesów strona kategorii filtrów. Filtrowanie według każdej z kategorii może być włączane bądź też wyłączne indywidualnie. Aby uaktywnić filtrację dla danej kategorii, przejdź do strony konfiguracyjnej tej kategorii i zaznacz pole wyboru Włącz (Enable) patrz Rysunek 5. Rysunek 5. Filtracja Request Metrics w konsoli administracyjnej Serwera Procesów włączanie kategorii filtrów. Page 9 of 26

Następnie w wybranej kategorii filtru powinieneś określić wartości filtrów, które zostaną zastosowane do selekcji nadchodzących żądań. Wszystkie aktualnie zdefiniowane wartości w formacie charakterystycznym dla danej kategorii filtracji wyświetlane są na stronie konfiguracyjnej Wartości filtru (Filter Values) patrz Rysunek 6. Rysunek 6. Filtracja Request Metrics w konsoli administracyjnej Serwera Procesów strona wartości filtrów. Podobnie jak w przypadku kategorii filtrów, również filtrowanie według każdej z wartości w danej kategorii może być kontrolowane indywidualnie poprzez stronę konfiguracyjną danej wartości. Przykładowo dla filtrowania nadchodzących zapytań w kategorii adresu źródłowego IP (SOURCE IP) dla adresu 10.10.10.101, wykonaj następujące kroki: Page 10 of 26

1. Na stronie Filtry pomiarów żądań ( Request Metrics Filter ) kliknij łącze kategorii SOURCE IP. 2. Kliknij łącze Wartość filtru (Filter Values) w sekcji Właściwości dodatkowe. 3. Kliknij przycisk Nowy (New). 4. Wpisz 10.10.10.101 do pola Wartość ( Value ) i zaznacz pole wyboru Włącz filtr (Enable filter), następnie zatwierdź konfigurację przyciskiem Zastosuj (Apply). 5. Wróć do strony konfiguracyjnej kategorii SOURCE IP. 6. Zaznacz pole wyboru Włącz (Enable) w sekcji Właściwości ogólne i zatwierdź konfigurację przyciskiem Zastosuj (Apply). 7. Zatwierdź zmiany w konfiguracji głównej Serwera Procesów klikając na łącze Zapisz (Save). Procedura testowa dla pomiarów wydajności aplikacji Serwera Procesów z użyciem narzędzia Request Metrics Na pierwszy rzut oka wydaje się, że przeprowadzenie pomiarów wydajności aplikacji dla Serwera Procesów z użyciem narzędzia Request Metrics jest banalnie proste potrzebne jest do tego jedynie odpowiednio skonfigurowane środowisko Serwera Procesów z zainstalowaną w nim aplikacją będącą celem testów oraz dowolne narzędzie do przesyłania testowych żądań. Jednak należy mieć na uwadze, że w porównaniu z innymi rodzajami pomiarów wydajności, które dostarczają statystyk uśrednionych, pomiary z użyciem narzędzia Request Metrics, z natury służącego do śledzenia pojedynczych transakcji, są znacznie bardziej wrażliwe nie tylko na warunki panujące w środowisku pomiarowym Serwera Procesów, ale również na zachodzące w nim zdarzenia przypadkowe. Dlatego też w celu upewnienia się, że wyniki pojedynczych pomiarów są wiarygodne i reprezentatywne dla badanej aplikacji, należy w procedurze pomiarowej zastosować podejście metodyczne, podobne do opisanej poniżej i wypracowanej doświadczalnie procedury testowej. Zawiera ona nie tylko szczegółowy opis zmian konfiguracyjnych przeprowadzanych w środowisku Serwera Procesów, ale uwzględnia także dodatkowe aspekty takie jak: Przygotowanie niezbędnych narzędzi i testowych danych wejściowych, Zapewnienie stabilnych i wiarygodnych warunków pomiaru w docelowym środowisku wykonawczym Serwera Procesów, Wyselekcjonowanie wyników pomiarów RM z plików systemowych dla następującej po pomiarach fazie ich analizy. dzienników Przygotowanie środowiska testowego Zalecaną architekturą środowiska testowego jest jego podział na dwa odseparowane komponenty: 1. Stacja robocza (zwana dalej również źródłową stacja roboczą) z zainstalowanym narzędziem do wysyłania żądań do testowanej złożonej aplikacji Serwera Procesów. Jako że w poniższych rozważaniach Page 11 of 26

uwzględniono jedynie eksport typu Web Service (WS) zgodnie z wcześniej uczynionym założeniem, wszystkie żądania będą nadsyłane w formie komunikatów SOAP odpowiadających udostępnionym interfejsom WS opisanym poprzez pliki WSDL. 2. Maszynę (nazywaną dalej serwerem docelowym) ze środowiskiem wykonawczym Serwera Procesów z zainstalowaną w nim testowaną złożoną aplikacją. Maszyna ta może być: Serwerem autonomicznym ( standalone server ) - najprostsze środowisko Serwera Procesów, Dedykowanym serwerem aplikacyjnym stanowiącym część klastra Serwera Procesów w złożonej topologii architektury rozwiązania Serwera Procesów. W celu uniknięcia wpływu zjawisk związanych z przesyłem danych w sieci komputerowej, najlepszym rozwiązaniem jest ulokowanie obu maszyn w tym samym segmencie sieci i połączenie ich za pomocą medium zapewniającego minimalne opóźnienie sygnału. Podstawowa funkcjonalność narzędzia zainstalowanego na źródłowej stacji roboczej sprowadza się głównie do wysyłania testowych komunikatów SOAP do określonego punktu końcowego Web Services, a więc można wybrać dowolne z wielu dostępnych narzędzi oprogramowania typu open-source, które zazwyczaj dostarczają znacznie bardziej wyrafinowaną funkcjonalność dodatkową. Ze względu na to, że narzędzie to może być również użyteczne dla innych czynności związanych z pomiarem wydajności takich jak wyznaczanie przepustowości czy czasów odpowiedzi, sensowne jest dobranie sprawdzonego i szeroko wykorzystywanego w branży narzędzia, które dodatkowo zapewnia określony stopień zautomatyzowania testów funkcjonalnych i testów obciążenia, tak jak wymienione poniżej następujące produkty open-source: SoapUI firmy Eviware (dowolny system operacyjny - język Java) TestMaker firmy PushToTest (dowolny system operacyjny - język Java) WebInject (dowolny system operacyjny język skryptowy Pearl) JMeter firmy Apache (dowolny system operacyjny - język Java) Chociaż wszystkie te narzędzia zapewniają pierwszorzędne wsparcie dla testowania funkcjonalności i efektywności usług sieciowych, doświadczenia autora skłaniają do sugestii skorzystania z produktu SoapUI firmy Eviware. Oprócz podstawowych cech tego narzędzia służących rozpoznawaniu, wywoływaniu i tworzeniu Web Services, jak również ich do ich funkcjonalnego i obciążeniowego testowania, SoapUI umożliwia ich symulacje i tworzenie imitacji. Dodatkowo zapewnia ono silne wsparcie języka skryptowego i kilka pomocnych narzędzi linii poleceń, które znacząco ułatwiają automatyzację testów. Poniżej przedstawiono kilka kroków związanych z przygotowaniem pomiarów wydajności z użyciem RM, w której zastosowano oprogramowanie SoapUI w wersji 2.5 jako przykładowe narzędzie do wykonania operacji przeprowadzanych na źródłowej stacji roboczej. Jeśli zamiast SoapUI zostanie użyte inne podobne narzędzie, to w opisanej procedurze należy podjąć odpowiednie równoważne działania dostępne w zastosowanym narzędziu. Page 12 of 26

Aby przygotować źródłową stację roboczą z zainstalowanym oprogramowaniem SoapUI do pomiarów wydajności aplikacji Serwera Procesów z użyciem RM, należy wykonać następujące kroki: 1. Utwórz nowy projekt i dodaj do niego plik WSDL związany z tym interfejsem Web Service udostępnianym przez aplikację Serwera Procesów, poprzez który aplikacja ma zostać przetestowana. Zaznacz opcję Create sample request for all operations w celu ułatwienia przygotowania żądań testowych. 2. Wybierz jedno z wygenerowanych żądań przykładowych dla danej operacji testowanego serwisu, a następnie: a. Przygotuj dedykowane żądanie testowe poprzez edycję utworzonego szablonu komunikatu SOAP, b. Sprawdź i w razie potrzeby zmień adres punktu końcowego WS (nazwę serwera lub jego numer IP oraz wartość portu HTTP) tak, aby wskazywał na serwer docelowy i testowaną aplikację, c. Wyślij żądanie testowe do aplikacji Serwera Procesów, d. Sprawdź poprawność otrzymanej odpowiedzi. 3. Utwórz przypadek testowy ( TestCase ) dla danej operacji interfejsu WS: a. Dodaj zweryfikowane żądanie testowe do przypadku testowego. Jeśli zestaw testowy ( TestSuite ) nie istnieje, to zostanie automatycznie wygenerowany w kreatorze wybierz domyślne opcje. b. Sprawdź asercje dodane do nowoutworzonego kroku testowego ( TestStep ) i uzupełnij je innymi asercjami niezbędnymi do automatycznej walidacji odpowiedzi. c. Pozostając w danym kroku testowym, wyślij ponownie żądanie i sprawdź otrzymaną odpowiedź w stosunku do ustawionych wcześniej asercji. 4. Przygotuj w podobny sposób kolejne żądania WS dla pozostałych operacji używanych w przypadkach pomiarowych, zgodnie z krokami 2 i 3 powyżej. Oprócz sprawdzenia funkcjonalnej i konfiguracyjnej poprawności zachowania się aplikacji Serwera Procesów z punktu widzenia konsumenta Web Services, niezbędne jest również dokładne zweryfikowanie poprawności operacyjnej aplikacji w środowisku wykonawczym Serwera Procesów. Należy przeglądnąć pliki dzienników systemowych serwera docelowego pod kątem występowania w nich błędów lub innych rekordów wskazujących na zagadnienia, które powinny zostać rozwiązane przed rozpoczęciem właściwej procedury testowej. Przygotowanie danych wejściowych Zgodnie z zaprojektowaną logiką biznesową testowanej złożonej aplikacji Serwera Procesów, nie wszystkie jej komponenty i moduły muszą być zaangażowane w dany przebieg programu. Na przykład dla aplikacji o diagramie przedstawionym na Rysunku 1 może istnieć scenariusz, w którym na skutek logiki zawartej w module BPEL1_MOD jedynie niektóre wartości pól wejściowych obiektów biznesowych powodują wywołanie modułu Output2_MED. Również reguły biznesowe zawarte w module BRules1_MOD mogą determinować wyznaczenie konkretnych adresów Page 13 of 26

punktów końcowych serwisów udostępnianych przez współpracujące systemy wewnętrzne. Dlatego też dla żądań zawierających różne dane wejściowe oraz dla różnych bieżących wartości reguł biznesowych w środowisku wykonawczym Serwera Procesów, możemy zaobserwować zróżnicowane zaangażowanie modułów uczestniczących w danym przebiegu programu. W konsekwencji wyniki pomiarów czasów odpowiedzi aplikacji mogą się znacząco różnić. Z powyższych rozważań wynika, że dane wejściowe żądania dla wykonywanych testów mogą wyznaczać ściśle określony przebieg programu, przekazując dane wyłącznie poprzez te komponenty i moduły aplikacji, które zostały przewidziane do pomiarów RM. Dlatego w większości przypadków zamiast pojedynczego żądania, należy przygotować zestaw żądań z odpowiednimi wartościami pól danych, które odzwierciedlają różne zaplanowane scenariusze przypadków użycia. W tej sytuacji dedykowane narzędzia stanowią wręcz nieocenioną pomoc na przykład poprzez wspomniane wyżej oprogramowanie SoapUI można sprawnie zorganizować dane wejściowe poprzez utworzenie indywidualnych żądań w postaci komunikatów SOAP w ramach przypadków testowych ( TestCases ), grupowanych poprzez zestawy testowe ( TestSuites ), co idealnie wpisuje się w potrzeby pomiarów z użyciem Request Metrics. Stabilizacja środowiska testowego Aby uzyskać wiarygodne wyniki pomiarów RM, niezbędne jest przeprowadzenie testowej procedury w stabilnych warunkach operacyjnych panujących w środowisku serwera docelowego. Taka stabilność oznacza po prostu, że większość realizowanych automatycznie wewnętrznych procesów związanych z zadaniami zarządzania środowiskiem wykonawczym takimi jak ładowanie modułów, wstępna kompilacja kodów skryptowych, inicjalizacja zasobów bazodanowych, pul połączeń, itp., jest już zakończona lub została poprawnie sfinalizowana. W przeciwnym wypadku wszystkie te procesy pracujące w środowisku serwera docelowego w momencie startu procedury pomiarów RM mogą wpływać na ich wyniki wnosząc rodzaj błędu systematycznego. W tej sytuacji pożądany stan ustalony serwera docelowego można osiągnąć poprzez wprowadzenie przed rozpoczęciem właściwych pomiarów tak zwanego okresu wygrzewania (warm-up), w którym do testowanej aplikacji wysyłane są takie same wejściowe żądania jak w procedurze pomiarowej RM, ale nie wykonuje się w tym czasie rejestracji danych. Długość tego okresu powinna być dobrana do potrzeb danej aplikacji, z uwzględnieniem wykorzystywanych przez nią zasobów i zależności od elementów środowiska. Prawidłowo wyznaczony okres wygrzewania zapewnia powtarzalne wyniki pomiarów RM zgrupowane wokół estymatorów wartości uśrednionych z akceptowalną wariancją estymatorów. Praktyczne przeprowadzenie wygrzewania dla środowiska docelowego aplikacji Serwera Procesów z wykorzystaniem narzędzia SoapUI i jego funkcjonalności testów obciążenia ( LoadTest ) może być zrealizowane w następujących krokach: 1. Uruchom program SoapUI na źródłowej stacji roboczej. 2. W lewym panelu wybierz odpowiedni zestaw testowy ( TestSuite ) oraz przypadek testowy ( TestCase ) przygotowany dla testu pomiarowego RM (patrz Rysunek 7). Page 14 of 26

3. Uruchom wstępny test przebiegu aplikacji poprzez wysłanie pojedynczego żądania SOAP do serwera docelowego: a. Kliknij dwukrotnie na nazwie przygotowanego żądania SOAP w obrębie kroków testowych ( Test Steps ) zestawu testowego ( TestSuite ), aby otworzyć okienko żądania. b. Kliknij ikonkę Submit. c. Po otrzymaniu odpowiedzi sprawdź jej poprawność w stosunku do asercji zdefiniowanych dla danego kroku testowego. Nawet jeśli poprawność otrzymanej odpowiedzi nie budzi zastrzeżeń, sprawdź dodatkowo pliki dzienników systemowych (SystemOut.log) na serwerze docelowym, czy nie pojawiły się w nich błędy lub innych rekordy wskazujące na zagadnienia wymagające rozwiązania przed rozpoczęciem właściwej procedury tesowej. Jeśli nie ma takich wpisów, przejdź do następnego kroku. 4. Kliknij dwukrotnie na zdefiniowanym dla Twojego scenariusza testowego teście obciążenia ( LoadTest ) w celu otwarcia okienka konfiguracyjnego i ustaw parametry scenariusza. Zalecane są dla nich następujące wartości: Limit= 60 Seconds, Threads= 1, Strategy= Simple, Test Delay= 0, Random= 0.0 (patrz Rysunek 7). 5. Uruchom scenariusz testowy poprzez kliknięcie ikonki Run (zielony trójkącik w lewym górnym rogu okienka). Po jego zakończeniu, powtórz tą samą akcję przynajmniej jeszcze dwa lub nawet więcej razy w celu ustabilizowania warunków pracy środowiska serwera docelowego. Każdorazowo po zakończeniu uruchomionego scenariusza, porównaj obliczane przez narzędzie SoapUI wartości wybranych statystyk pomiarowych (wartość średnia czasu odpowiedzi avg oraz przepustowość tps ) z wartościami uzyskanymi dla scenariuszy poprzednich. Powtarzalne podobne liczby będą świadczyć o tym, że stan ustalony na serwerze docelowym został osiągnięty. Rysunek 7. Wykorzystanie funkcjonalności testów obciążenia narzędzia soapui do stabilizacji środowiska testowego. Page 15 of 26

Na zakończenie, a ciągle jeszcze przed uruchomieniem pomiarów RM, należy upewnić się, że serwer docelowy nie jest zaangażowany w inne działania, takie jak obsługa żądań innych klientów czy też wykonywanie jakiś mocno obciążających zadań systemowych, ponieważ w takiej sytuacji serwer nie będzie w stanie zapewnić swojej maksymalnej wydajności podczas przeprowadzania testów. Rzeczywiste bieżące obciążenie serwera docelowego można sprawdzić poprzez proste monitorowanie zasobów systemowych fizycznej maszyny z wykorzystaniem narzędzi wbudowanych w system operacyjny, takich jak polecenie top w systemie Unix, polecenie topas dla systemu AIX lub też aplikację Task Manager w systemach Windows. Wykonywanie testu pomiarowego Request Metrics Ostatecznie po zakończeniu przygotowania środowiska testowego oraz potwierdzeniu bieżących warunków jego pracy, można przystąpić do właściwych pomiarów RM dla testowanej aplikacji Serwera Procesów. Załóżmy, że chcemy uzyskać szczegółowy obraz przepływu komunikatów przez wszystkie komponenty aplikacji. W tym przypadku należy przyjąć typowe ustawienia konfiguracyjne instrumentacji RM na serwerze docelowym (patrz Rysunek 3 w podrozdziale Ogólna konfiguracja narzędzia Request Metrics ), których dokonuje się w konsoli administracyjnej ISC: 1. Zaznacz pole wyboru Przygotuj serwery na zbieranie pomiarów żądań (Prepare servers for request metrics collection). Page 16 of 26

2. Ustaw opcję Komponenty do instrumentacji (Components to be instrumented) na Wszystko (All). 3. W polu Poziom śledzenia (Trace level) wybierz opcję Debugowanie (Debug). 4. W sekcji Docelowe miejsce pomiarów żądań (Request metrics Destination) zaznacz pole wyboru Dzienniki standardowe (Standard Logs) oraz nie zaznaczaj pola Agent ARM (Application Response Measurement (ARM) agent). 5. Kliknij przycisk Apply (Zastosuj), aby zatwierdzić wprowadzone zmiany, a następnie potwierdź zapisanie aktualnej konfiguracji. W tym początkowym stadium pomiarów RM z reguły nie jest potrzebne stosowanie filtracji RM, chociaż ta funkcjonalność może być pożyteczna w przypadku napotkania jakiś problemów wydajnościowych. Ponieważ rekordy RM będą zapisywane w standardowych plikach dzienników Serwera Procesów (pliki SystemOut.log), należy dodatkowo sprawdzić aktualną konfigurację związaną z dziennikami JVM w środowisku serwera docelowego, aby upewnić się, że żadne dane pomiarowe nie zostaną utracone. Taka sytuacja mogła by mieć miejsce w przypadku pozostawienia domyślnych ustawień Rotacja pliku dziennika ( Log File Rotation ) z wartością Wielkość pliku ( File Size ) równą 1 MB oraz wartością 1 dla ilości historycznych plików dziennika. Rekomendowane wartości konfiguracyjne są następujące: Zaznaczona opcja wyboru Rotacja pliku dziennika - Wielkość pliku (Log File Rotation File Size), Wielkość maksymalna (Maximum Size) ustawiona na 5 MB. Maksymalna liczba historycznych plików dzienników Number of Historical Log Files) ustawiona na 10. (Maximum Wartości te można skonfigurować poprzez konsolę administracyjną ISC, na przykład poprzez ścieżkę: Rozwiązywanie problemów -> Dzienniki i dane śledzenia -> <nazwa_serweraprocesów> -> Dzienniki maszyny JVM (Troubleshooting -> Logging and Tracing -> <your_processserver_name> -> JVM Logs) Teraz pozostaje już tylko uruchomienie narzędzia wybranego do wysyłania żądań wejściowych do testowanej aplikacji Serwera Procesów i rozpoczęcie transmisji przygotowanego komunikatu. Po otrzymaniu odpowiedzi należy powtórzyć tą samą akcję przynajmniej dwukrotnie, aby uzyskać próbkę statystyczną dla danego przypadku testowego. W oparciu o narzędzie SoapUI powyższe działanie można wykonać mieć następujący przebieg: Przejdź do wybranego zestawu testowego ( TestSuite ), Wybierz odpowiedni przypadek testowy ( TestCase ), Page 17 of 26

Kliknij dwukrotnie na określonym żądaniu SOAP w obrębie kroku testowego ( Test Steps ) i wyślij to żądanie do zdefiniowanego poprzez adres URL punktu końcowego. Po otrzymaniu odpowiedzi, obserwuj jej walidację w stosunku do przyjętych asercji (zielona kropka oznacza poprawną walidację) oraz czas odpowiedzi (patrz Rysunek 8). Dzięki tym wskaźnikom możesz łatwo porównywać różne przypadki testowe. Podobne czasy odpowiedzi dla kolejno wysyłanych żądań wskazują na to, że pomiary przebiegają prawidłowo. Rysunek 8. Wysyłanie żądań do aplikacji Serwera Procesów poprzez narzędzie soapui Ponieważ najprawdopodobniej nie będzie potrzeby dalszego zbierania danych RM po zakończeniu procedury pomiarowej, należy dezaktywować tą funkcję poprzez konsolę administracyjną ISC serwera docelowego na stronie konfiguracyjnej Request Metrics (patrz Rysunek 3). Odbywa się to poprzez zmianę ustawienia opcji Komponenty do instrumentacji (Components to be instrumented) z wartości Wszystko (All) na wartość Brak (None), a następnie zatwierdzenie zmiany przyciskiem Apply (Zastosuj). Page 18 of 26

Wyselekcjonowanie danych Request Metrics z plików dzienników SystemOut Może się zdarzyć, że rekordy RM znajdą się nie tylko w najbardziej aktualnym pliku dziennika o SystemOut.log, ale będą rozproszone w innych historycznych plikach dzienników SystemOut_*.log. Przyczynami takiej sytuacji mogą być: Duża ilość danych RM gromadzonych podczas pomiarów testowych, Bieżąca konfiguracja plików dzienników JVM dla Serwera Procesów (patrz podrozdział Wykonywanie testu pomiarowego Request Metrics ) Wielkość pliku SystemOut.log tuż przed rozpoczęciem pomiaru testowego. Inny problem związany z analizą wyników pomiaru RM może dotyczyć faktu, iż rekordy RM stanowią w zasadzie jeden rodzaj z całej gamy różnorodnego typu innych wpisów znajdujących się w dzienniku systemowym SystemOut.log. Aby więc zawęzić analizę wyłącznie do zebranych rekordów RM, należy wyselekcjonować je z plików dziennika. Bazując na podejściu zaproponowanym przez Ken Gottry ego w [2] i starając się wykorzystywać ogólnie dostępne i standardowe narzędzia wszędzie, gdzie tylko to jest możliwe, rekomendowane jest zastosowanie do powyższego zadania narzędzia o nazwie grep, mającego swój rodowód w systemie Unix (ale również oferowanego w wielu wersjach i odmianach dla systemów Windows). Wybór tego narzędzia do wstępnego przetworzenia plików dzienników SystemOut_*.log w celu wyselekcjonowania z nich rekordów RM został podyktowany następującymi względami: Każdy rekord RM w danym pliku SystemOut_*.log jest wyróżniony ciągiem znaków PMRM0003I (patrz Rysunek 2), co stwarza możliwość ich wyszukania w pliku tekstowym poprzez znalezienie wierszy zgodnych ze wyspecyfikowanym wzorcem ta cecha stanowi właśnie podstawową funkcjonalność polecenia grep. Rezultatem polecenia grep są po prostu wiersze tekstu zawierające ciąg znaków odpowiadający zadanemu wzorcowi, które można łatwo przekierować do innego pliku wynikowego. Polecenie grep może przeszukiwać jeden lub więcej plików wejściowych. Gdy istnieją dopasowania do wzorca w wielu plikach wejściowych, grep dodaje na początku znalezionego wiersza unikatowy łańcuch w postaci nazwa_pliku:, co pozwala na bezpośrednią identyfikację źródłowego pliku dla danego wiersza. Na przykład w celu przygotowania nowego zbioru danych o nazwie RMrecords.txt zawierającego wyłącznie rekordy RM wyselekcjonowane z wielu plików SystemOut_*.log Serwera Procesów, należy wprowadzić w katalogu /logs tego serwera następującą komendę: grep "PMRM0003I" SystemOut*.log > RMrecords.txt Przykładową zawartość tak utworzonego pliku RMrecords.txt ukazano na Rysunku 9. Rysunek 9. Przykładowa zawartość nowego pliku danych zawierającego wyłącznie rekordy RM Page 19 of 26

Przygotowany w powyższy sposób plik danych gromadzi wyniki pomiarów RM w tekstowym formacie wygodnym do dalszego przetwarzania przy użyciu innych popularnych narzędzi jak skrypty AWK proponowane w [2], arkusze kalkulacyjne, niestandardowe programy przygotowane w dowolnych językach programowania lub też specjalnie przygotowanego przez autora programu Java opisanego szczegółowo w kolejnym rozdziale. Przetwarzanie wyników pomiarów Request Metrics Jak wspomniano na początku artykułu, najbardziej pożądanym rezultatem analizy pomiarów RM jest przedstawienie obrazu wszystkich transakcji zainicjowanych podczas wykonanego testu, który musi opierać się o dane korelacyjne zawarte w rekordach RM. Jedną z wielu możliwych wizualizacji jest drzewo logiczne reprezentujące postęp żądania przechodzącego przez komponenty aplikacji Serwera Procesów. Dla tego rodzaju widoku hierarchicznej struktury danych można wykorzystać dedykowane komponenty wizualne popularnych pakietów oprogramowania. Na przykład dla języka Java pakiet Swing zawiera klasę JTree, a w związanym ze środowiskiem Eclipse pakiecie SWT (Standard Widget Toolkit) możemy znaleźć widżet Tree. Niezależnie od decyzji związanej z wyborem komponentów wizualnych zastosowanych w tworzonej aplikacji niestandardowej do zobrazowania wyników analizy pomiarów RM, wszystkie wpisy rekordów RM znajdujące się w pliku wejściowym muszą wcześniej zostać przetworzone i odpowiednio ze sobą skorelowane. Aby zatem przedstawić wyniki pomiarów RM w formie widoku drzewa, niestandardowa aplikacja powinna realizować następujące operacje: Page 20 of 26