Czy nasz system jest wydajny?

Na to pytanie stosunkowo łatwo jest odpowiedzieć, posiłkując się danymi dostępnymi w systemie SAP. Mamy do dyspozycji sporo informacji statystycznych dostępnych poprzez popularny Monitor obciążenia systemu (transakcja ST03).

Możemy też „pójść do źródła” i zapytać użytkowników, jakie są ich odczucia związane z codzienną pracą z systemem. Oczywiście te opinie są subiektywne i nieprecyzyjne, jednak stwierdzenie, że system „wolno chodzi”, może być przesłanką do przeprowadzenia monitoringu obciążenia.

Jeśli sygnały płynące z systemu bądź od użytkowników wskazują na problemy natury wydajnościowej, sytuacja wymaga analizy. Szukanie powodów niskiej wydajności w systemach SAP jest zagadnieniem złożonym i dotyka wielu elementów. Począwszy od samego systemu SAP i jego komponentów, poprzez system operacyjny i bazę danych, a na warstwie sprzętowej kończąc.

Analizę problemów związanych z wydajnością warto powierzyć specjalistom IT z dużym doświadczeniem, ponieważ prawidłowa interpretacja informacji płynących z systemu wymaga szerokiej wiedzy technicznej, ale także dotyczącej samego systemu.

Często specjaliści IT klienta, którzy na co dzień zajmują się ograniczoną liczbą systemów, nie mają możliwości porównania odpowiednich parametrów z innymi systemami. Taką wiedzę i doświadczenie posiadają konsultanci pracujący z wieloma instalacjami. Trafna diagnoza problemów wydajnościowych opiera się bardzo często na wiedzy, obserwacji i porównaniu z innymi systemami. Kluczem jest tutaj doświadczenie.

Wydajność systemu po zmianach

Często problemy wydajnościowe pojawiają się w wyniku konkretnych działań, np. wdrożenia nowych funkcjonalności, zwiększenia liczby użytkowników, zmiany platformy sprzętowej itp.

Czy system będzie wydajny po zmianach? To pytanie zadaje sobie z pewnością wiele osób odpowiedzialnych za implementację zmian w systemach SAP. Jednak odpowiedź na nie jest prosta.

Można próbować szacować wpływ dokonanych zmian na działanie systemu. W niektórych przypadkach, na przykład gdy wprowadzamy pojedyncze niewielkie zmiany w systemie, taka sztuka może się udać. Jednak w większości przypadków jednoznaczna odpowiedź bez przeprowadzenia odpowiednich testów nie jest możliwa.

Zanim wprowadzimy w życie zmiany w systemie produktywnym, dobrze jest wykonać testy na systemie testowym. Optymalnym rozwiązaniem byłoby, aby platforma sprzętowa dla obu systemów (produktywnego i testowego) była zbliżona. Jednak nawet jeśli tak nie jest, to testy dostarczą wielu informacji, które pozwolą potwierdzić lub odrzucić tezę, że system będzie wydajny po zmianach.

Testowanie

Najtrudniejszym elementem testów wydajnościowych jest wygenerowanie odpowiedniego obciążenia, czyli zasymulowanie pracy użytkowników w systemie. Niewiele przedsiębiorstw może sobie pozwolić na przeprowadzenie takich testów z udziałem rzeczywistych użytkowników. Dodatkowo jest wskazane, aby taki test można było uruchomić kilkakrotnie z takimi samymi warunkami – ważna jest więc powtarzalność takiej operacji.

Celem testów jest weryfikacja wydajności, ale przy tej okazji możliwa jest również odpowiedź na inne pytania, np. jaka jest granica obciążenia naszego systemu (ilu użytkowników?, ile operacji?).

Nie trudno się domyślić, że aby precyzyjnie sterować przebiegiem testu, źródło naszego obciążenia musi być elastyczne i posiadać wiele możliwości konfiguracyjnych.

Generowanie obciążenia

Spośród dostępnych na rynku narzędzi do generowania obciążenia systemów IT wiodącym i sprawdzonym w środowisku SAP produktem jest HP LoadRunner (znany też pod nazwą SAP LoadRunner by HP).

Za pomocą tego rozwiązania można przygotować i wykonać szereg testów zarówno systemów SAP opartych na środowisku ABAP, gdzie klientem jest SAP GUI, jak również systemów, w których interfejsem jest przeglądarka internetowa, np. SAP Enterprise Portal.

Działanie oprogramowania LoadRunner bazuje na wirtualnych użytkownikach (Vuser), którzy wykonują przygotowane wcześniej skrypty testowe. A całość operacji jest sterowana centralnie z kontrolera.

Działanie narzędzia HP LoadRunner

Przygotowanie testu powinniśmy rozpocząć od ustalenia, co chcemy testować i jaki ma być rezultat testu. Należy wybrać zbiór operacji (transakcji), które będą testowane, oraz postarać się pogrupować je tak, aby możliwe było przypisanie ich do określonych użytkowników wirtualnych.

Kolejnym i zarazem jednym z najbardziej krytycznych kroków będzie opracowanie skryptów testowych. Skrypty testowe to zapis operacji, które ma wykonać wirtualny użytkownik podczas testów.

Właściwe przygotowanie skryptów wymaga zaangażowania zarówno osoby dobrze znającej system SAP i narzędzie LoadRunner, jak również doświadczonego użytkownika, który dobrze zna sekwencję wykonywanych na co dzień operacji. Skrypt testowy musi wiernie odwzorować operacje, które wykonują prawdziwi użytkownicy, pracując z systemem.

Przygotowane skrypty należy też dokładnie zweryfikować, biorąc pod uwagę, że każdy z nich będzie wykonywany wielokrotnie przez wielu użytkowników, co może prowadzić do wzajemnych zależności, np. blokowanie określonych dokumentów podczas przetwarzania przez jednego z użytkowników itp.

Ze skryptami testowymi wiąże się przygotowanie danych testowych. Wszystkie wartości, które rzeczywisty użytkownik wprowadza do systemu, muszą zostać opracowane i przypisane do odpowiednich miejsc w skryptach testowych.

Po przygotowaniu i przetestowaniu skryptów możemy określić dokładny scenariusz uruchamiania testu. Ilu użytkowników będzie wykonywać określony skrypt testowy, z jaką intensywnością, czy poszczególne operacje mają się uruchamiać losowo z założonym prawdopodobieństwem, czy może chcemy, aby sekwencja operacji wykonywała się zawsze tak samo? Na takie i podobne pytania będziemy musieli odpowiedzieć, bazując na założonych celach testu oraz znajomości systemu SAP.

Istotną kwestią jest również właściwe rozdystrybuowanie wirtualnych użytkowników na fizyczne hosty, na których będą działały generatory obciążenia (Load Generator), tak aby zniwelować potencjalny wpływ środowiska testowego na wynik samych testów.

W dobrze przygotowanym środowisku samo uruchomienie testu jest prostą operacją i, co bardzo istotne, operacją, którą można powtarzać  wielokrotnie, bazując na raz przygotowanym scenariuszu testowym. W trakcie działania testu powinniśmy monitorować jego wykonanie, reagując na ewentualne nieprawidłowości (np. zbyt duża liczba przerwanych transakcji może wskazywać na błędy w skryptach).

Testy kończą się analizą wyników.

Całość czynności, które należy wykonać, możemy zgrupować w 6 krokach:

  • planowanie testu,
  • tworzenie skryptów,
  • tworzenie scenariusza,
  • uruchomienie testu,
  • monitorowanie wykonania,
  • analiza wyników.

Wyniki testów

Kiedy za pomocą oprogramowania LoadRunner testujemy systemy SAP, jesteśmy w komfortowej sytuacji. Mamy do dyspozycji zarówno wyniki dostarczone przez oprogramowanie LoadRunner, jak również dane, które zebrał SAP.

W oprogramowaniu HP LoadRunner wyniki są prezentowane w postaci raportu opisującego przede wszystkim poszczególne operacje (transakcje), z podaniem czasu wykonania, średnich i odchylenia. Raport zawiera również informację o sposobie uruchomienia testu i parametrach.

Doskonałym uzupełnieniem danych dostarczonych z oprogramowania LoadRunner są informacje dostępne w systemie SAP zebrane w czasie trwania testu. W systemie mamy do dyspozycji dużą liczbę wartości, które obrazują wydajność systemu. Warto tu wspomnieć choćby o popularnej wartości, jaką są średnie czasy odpowiedzi dla kroków dialogowych, powszechnie wykorzystywane jako jeden z głównych wskaźników wydajności systemu SAP.

Zastosowanie oprogramowania HP LoadRunner pozwoli nam osiągnąć dodatkowe korzyści:

  • raz przygotowane skrypty testowe mogą być wykorzystywane wielokrotnie;
  • ten sam skrypt lub zestaw skryptów można uruchomić na wielu systemach (w niektórych przypadkach zachodzi potrzeba drobnych adaptacji);
  • na podstawie tych samych skryptów można wygenerować obciążenie o różnym charakterze (zarówno obciążenie, które symuluje normalną pracę użytkowników, jak również obciążenie wielokrotnie wyższe, np. aby określić granice wytrzymałości systemu);
  • mamy pełną kontrolę nad przebiegiem testu i możemy go odpowiednio sparametryzować;
  • otrzymujemy precyzyjne wyniki opisujące wykonanie poszczególnych operacji testowych;
  • możemy dobrać liczbę wirtualnych użytkowników do naszych potrzeb testowych i rozlokować ich na wielu hostach fizycznych;
  • symulacja użytkownika odbywa się na poziomie protokołu, a zatem system traktuje użytkowników wirtualnych podobnie jak rzeczywistych – nie ma więc wpływu na wynik testu;
  • sterowanie całym procesem odbywa się z jednego miejsca (tzw. kontroler).

Testy i co dalej?

Kiedy mamy już w ręku wyniki naszych testów, oceniamy, czy wydajność sprawdzonych systemów jest zgodna z oczekiwaniami. Jeśli tak, to oczywiście możemy spokojnie korzystać z systemów, pamiętając jednak, że testy warto przeprowadzać cyklicznie. Zaplanujmy więc kolejne np. za pół roku. Dzięki temu łatwiej będzie kontrolować zmiany wydajności i szacować, jakie są tendencje. To z kolei pozwoli na planowanie wydatków i zasobów koniecznych do prac rozwojowych.

Jeśli zaś wyniki testów wykażą niesatysfakcjonującą wydajność systemu, pozostaje nam przeprowadzić wspomnianą już analizę problemów i usunąć tzw. „wąskie gardła” systemu. W tym przypadku cenna może się okazać pomoc doświadczonych specjalistów.