Archive for Luty, 2011

Zmiana rozdzielczości w X-server przy użyciu polecenia

Od czasu do czasu muszę podłączyć laptopa do rzutnika, co w moim przypadku wiąże się z reguły z koniecznością zmiany rozdzielczości na niższą. Można zrobić oczywiście przy pomocy menu konfiguracyjnego i wybranie odpowiedniej opcji, ale chciałbym to móc zrobić przy użyciu polecenia.

Polecenie które umożliwia zarządzanie rozdzielczością wyświetlania na ekranie nazwy się xrandr. Pozwala ono na ustawienie rozmiaru oraz orientacji ekranu. Domyślnie zdefiniowane rozdzielczości można sprawdzić przy pomocy przełącznika -q:

$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 175, current 1920 x 1200, maximum 1920 x 1200
default connected 1920x1200+0+0 0mm x 0mm
   1920x1200      50.0*    51.0     52.0     53.0  
   1920x1080      54.0  
   1680x1050      55.0     56.0

Jeżeli mam ochotę na ustawienie rozdzielczości 1680×1050, wystarczy że wydam polecenie:

$ xrandr -s 1

Numeracja rozdzielczości zaczyna się od zera.

To oczywiście jest najprostsze użycie tego polecenia. Można także definiować własne tryby, łącznie z takimi gdzie obszar pulpitu jest większy od rozdzielczości ekranu. Można także zdefiniować własny kształt ekranu, np. w formie trapezu. Pozwoli on na kompensację błędnego działania rzutnika (przykład ze strony MAN polecenia):

xrandr --fb 1024x768 --output VGA --transform 1.24,0.16,-124,0,1.24,0,0,0.000316,1

Źródła

Tags: , , ,

JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 2

Druga część wpisu poświęconemu tworzeniu przy użyciu JMeter planu testów aplikacji napisanej za pomocą szkieletu JBoss Seam.

Przygotowanie testu do obsługi aplikacji napisane w JBoss Seam

Można teraz spróbować uruchomić test. Jeżeli testujemy aplikację napisaną w JBoss Seam, prawdopodobnie żadna strona nie zostanie wczytana (można to potwierdzić np. patrząc na zawartość pliku localhost_access_log) a serwer aplikacji wyrzuci stos wyjątków mówiącymi, że nie można odzyskać widoku. Spowodowane jest to tym, że Seam zapisuje na stronach oraz często w URL lub w wysyłanych formularzach dodatkowe wartość, które określają nazwę danego widoku raz numer konwersacji. Można sobie z tym poradzić, ale wymaga to dodatkowej pracy nad testem.

Trzeba będzie sobie poradzić z dwoma elementami: widokiem oraz konwersacją.

  • ViewState

    W przypadku widoku należy po kolej przejrzeć w aplikacji JMeter każde zapytanie, które zostanie wysłane do serwera aplikacji. Należy odszukać te strony, które zawierają w parametrach odwołanie do ciągu znakowego: javax.faces.ViewState. Powinna być tam określona wartość tego parametru, w moim przypadku było to j_id1:j_id2. W moim przypadku wywołanie to znajdowało się na drugiej stronie, w której następowało logowanie do aplikacji.

    JMeter - ViewState

    JMeter - ViewState

    Po identyfikacji właściwej strony należy należy teraz odszukać wywołanie poprzednie. Wartość dla parametru javax.faces.ViewState jest ustawiana w poprzednim wywołaniu, więc tam należy tę wartość przechwycić. Można to zrobić dodając do strony poprzedzającej to wywołanie komponent o nazwie Regular Expression Extractor, znajdujący się w menu Post Processors i go odpwiednio skonfigurować:

    • Name: ViewState Extractor – nazwa komponentu
    • Reference Name: VIEWSTATE – nazwa zmiennej, która będzie użyta do podstawienia wartości
    • Regular Expression: id="javax.faces.ViewState" value="([^"]*)" – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
    • Template: $1$
    • Match No.: 1
    JMeter - ViewState Extractor

    JMeter - ViewState Extractor

    Teraz jeszcze należy odpowiednio ustawić wartość dla parametru javax.faces.ViewState. Czyli trzeba otworzyć stronę na której występowało odwołanie do parametru i zmienić jego wartość na odwoła nie do zmiennej ${VIEWSTATE}.

    JMeter - konfiguracja zmiennej VIEWSTATE

    JMeter - konfiguracja zmiennej VIEWSTATE

    Jeżeli odwołanie do parametru javax.faces.ViewState występuje także na innych stronach, to także trzeba będzie takie zmiany wprowadzić. W moim przypadku wywołanie występowało na 5 stronach.

  • Konwersacje

    Konwersacje są jedną z włąściwości szkieletu JBoss Seam wyróżniającego go spośród innych rozwiązań (więcej na ten temat można znaleźć w manualu: Conversations and workspace management). W aplikacji Seamowej można zauważyć, że duża część linków zawiera dodatkowy parametr o nazwie conversationId czy też cid. Określa on numer określonej konwersacji, i wymaga także odpowiedniego potraktowania przez narzędzie testujące.

    Sposób radzenia sobie z konwersacjami jest podobny jak przy problemie z ViewState: należy odszukać wszystkie wystąpienia danej konwersacji i odpowiednio zmienić je na wywołania zmiennej.

    • najpierw należy zidentyfikować nazwę parametru używanego przez aplikację, może to być np. conversationId lub cid
    • odszukać wystąpienia tego parametru, powinien być przekazywany przy użyciu linku, czyli metodą GET, w moim przypadku jest to czwarta strona, wyświetlająca produkt:

      JMeter - wywołanie conversationId

      JMeter - wywołanie conversationId

    • należy do poprzedniej strony (analogicznie jak w przypadku ViewState) dodać komponent Regular Expression Extractor i go odpowiednio skonfigurować:
      • Name: ConversationID Extractor – nazwa komponentu
      • Reference Name: CID – nazwa zmiennej, która będzie użyta do podstawienia wartości
      • Regular Expression: conversationId=(\d+) – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
      • Template: $1$
      • Match No.: 1
      JMeter - ConversationID Extractor

      JMeter - ConversationID Extractor

    • odszukać wystąpienia danej konwersacji na następnych stronach i za wartość podstawić zmienną ${CID}:

      JMeter - konfiguracja zmiennej CID

      JMeter - konfiguracja zmiennej CID

    • powyższe kroki trzeba powtórzyć dla każdego numeru konwersacji (czyli jak zmienia się jej numer, to należy użyć wyrażenia regularnego do jego uzyskania, i następnie podstawiać tę wartość na następnych wywołaniach strony), w moim przykładzie należało użyć wyrażenia regularnego 3 razy i podmienić na zmienną 8 wartości

Po powyższych zmianach można uruchomić test i powinien już zadziałać bez problemów.

Uruchomienie testu

Ostatnim elementem testu będzie uruchomienie go w kilku wątkach oraz konfiguracja JMetera tak, aby używał do logowania kont różnych użytkowników.

Za zarządzanie użytkownikami odpowiada kontroler User Parameters. Pozwala on na zdefiniowanie użytkowników, jacy mogą zostać użyci w trakcie testu.

W ramach tego komponentu należy zdefiniować nazwę zmiennej która będzie używana do podstawienia za login oraz hasło użytkownika. W kolejnych kolumnach należy zdefiniować wartości dla tych zmiennych.

W przypadku aplikacji DVD Store występuje pięciu użytkowników o nazwach od user1 do user5, wszyscy z hasłem pasword. Definicja dla nich może wyglądać następująco:

JMeter - definicja użytkowników

JMeter - definicja użytkowników

Należy jeszcze zmodyfikować odpowiednio proces logowania do aplikacji, i zamiast wysyłania wartości w formularzu, wstawić odpowiednie zmienne JMeter:

JMeter - modyfikacja formularza logowania

JMeter - modyfikacja formularza logowania

Ostatnim elementem będzie uruchomienie większej ilości wątków i przetestowanie aplikacji. Można to zrobić w ramach komponentu Thread Group. W nim ustala się następujące parametry:

  • Number of Threads – ilość jednocześnie uruchamianych wątków, jeden wątek odpowiada jednemu użytkownikowi, jeżeli wątków będzie więcej niż zdefiniowanych użytkowników, to od nowa brany jest do logowania pierwszy użytkownik i potem następni
  • Ramp-Up Period – po jakim czasie wszystkie wątki mają działać, czyli ustawienie tu wartości na 5 sekund przy 5 wątkach spowoduje, że każdy wątek będzie uruchamiany co sekundę
  • Loop Count – ilość powtórzeń testów

Przykładowa konfiguracja może wyglądać tak:

JMeter - definicja sposobu uruchamiania testu

JMeter - definicja sposobu uruchamiania testu

Pozostaje teraz zdefiniować obciążenie serwera, uruchomić test i oglądać jak wygląda obiciążenie i kiedy serwer przestanie odpowiadać na zapytania.

JMeter - wyniki testu

JMeter - wyniki testu

Na koniec przygotowany plan testów dla aplikacji: Plan testu DVD Store.

Źródła

Tags: , ,

JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 1

Ostatnimi czasy musiałem przygotować test wydajności dla aplikacji stworzonej przy użyciu szkieletu JBoss Seam. I okazało się, że nie do końca jest to takie trywialne. Poniżej opis, jak przygotować plan testu dla takiej aplikacji (oczywiście, spokojnie można go także użyć do budowy testu dla dowolnej aplikacji webowej).

Wpis składa się z dwóch części:

Oprogramowanie

W trakcie konstruowania testu używałem następujących aplikacji:

  • JMeter 2.3.4
  • JBoss EAP 5.1
  • JBoss DVD Store – aplikacja przykładowa dostarczana z biblioteką JBoss Seam 2.2.1

Przed przystąpieniem do budowy testu należy aplikację DVD Store zainstalować w serwerze aplikacyjnym.

Jeżeli będziemy się łączyli bezpośrednio z serwerem aplikacyjnym (np. używają linku http://localhost:8080/seam-dvdstore, to warto jeszcze dodać do niego możliwość logowania przychodzących połączeń HTTP. Może to się przydać, aby sprawdzić czy wszystko, czy nie występują jakieś błędy. Można to zrobić modyfikując plik $JBOSS_HOME//server/default/deploy/jbossweb.sar/server.xml. Należy w nim odkomentować nastepujący linie (więcej informacji na ten temat można znaleźć we wpisie Logowanie przychodzących połączeń HTTP w serwerze JBoss AS i Apache Tomcat):

80
81
82
83
<valve className="org.apache.catalina.valves.AccessLogValve"
   prefix="localhost_access_log." suffix=".log"
   pattern="common" directory="${jboss.server.log.dir}"
   resolveHosts="false" />

Plik z logiem będzie znajdował się w katalogu z logami: $JBOSS_HOME//server/default/log/localhost_access_log.DATA.log.

Zebranie danych do testowania

Pierwszym krokiem będzie zebranie stron, na których będzie wywoływany test. Można to zrobić na dwa sposoby:

  • zdefiniować wywołanie każdej strony ręcznie
  • użyć modułu proxy, który umożliwi nagranie sesji przy użyciu przeglądarki

Ponieważ drugi sposób będzie szybszy, to za jego pomocą nagramy sesję przeglądarki. JMeter udostępnia odpowiedni komponent, który działa jak serwer proxy i pozwala przechwycić żądania z przeglądarki. Konfiguracja jest prosta:

  • w JMeter należy dodać następujące komponenty:
    • do Test Plan komponent Thread Groupp – pozwala on na konfigurację przebiegu testu: ilość użytkowników, uruchomionych wątków, co ma się dziać w momencie wystąpienia błędu
    • do Thread Group dodać kontroler Recording Controller – zostaną w nim zapisane wszystkie przechwycone żądanie z komponentu proxy
    • do WorkBench dodać komponent HTTP Proxy Server – to jest nasz serwer proxy, pozwala on na konfiguracja kilku zachowań, teraz najważniejsz będzie port na którym zostanie on uruchomiony. W domyślnej konfiguracji jest to port 8080, które jest zajęty przez proces JBossa, należy więc zmienić go na jakiś inny, np. 9000.

      Wybór portu dla HTTP Proxy Server

      Wybór portu dla HTTP Proxy Server

  • skonfigurować odpowiednio przeglądarkę internetową, tak aby korzystała z serwera proxy. W przypadku Firefoksa powinno wyglądać to mniej więcej tak:
    Konfiguracja serwera proxy w Firefoksie

    Konfiguracja serwera proxy w Firefoksie

    Należy zwrócić uwagę na pole No Proxy for, domyślnie znajduje się tam wartość localhost, co może uniemożliwić nagranie sesji, jeżeli serwer JBoss jest uruchamiany na maszynie lokalnej.

Teraz czas na pobranie kilku stron, które będą używane następnie w trakcie testu. Należy jeszcze włączyć serwer proxy: w komponencie HTTP Proxy Server należy wybrać przycisk Start. W przypadku aplikacji DVD Store można wykonać takie kroki:

  • połączyć się ze stroną http://localhost:8080/seam-dvdstore/home
  • można zalogować się na konto wybranego użytkownika, w tym przypadku będzie to użytkownik user1
  • następnie obejrzeć jedną, dwie płyty
  • dodać płytę do koszyka i złożyć zamówienia
  • wylogować się

Te kroki powinny spowodować, że w aplikacji JMeter pojawi się pod komponentem Record Controler szereg zapytań o strony. Można zauważyć, że znajdują się tam wszystkie wywołania HTTP które wygenerowała przeglądarka, czyli łącznie z pobraniem obrazków, arkuszy stylów czy skryptów JavaScript. W moim przypadku skasowałem te wpisy. W przypadku gdy chcemy pobierać dodatkowe elementy strony, można w ramach zapytania o stronę w JMeter zaznaczyć opcję Retrive All Embedded Resources from HTML files.

W moim przypadku nagrana sesja wygląda następująco:

Nagrana sesja zapytań HTTP

Nagrana sesja zapytań HTTP

Uporządkowanie testu

Nagrane zapytania do serwera można teraz uporządkować wg funkcji które wykonują oraz trzeba jeszcze dodać kilka dodatkowych komponentów do projektu.

  • HTTP Cookie Manager – pozwala on na zarządzanie ciasteczkami, które są ustawiane przez badaną stronę
  • Graph Results – tworzy wykres w trakcie uruchamianie testu, można także dodać jakieś inne elementy, które będą zbierały dane z testu
  • Simple Controller – dodanie kilku (w tym przypadku 4) kontrolerów, które pozwolą na pogrupowanie zapytań do serwera
  • usunąć komponent Record Component

Grupowanie nie ma wpływu na sam test, ale na pewno zwiększy przejrzystość poszczególnych elementów testu.

Po uporządkowaniu zapytań, wygląda to następująco:

JMeter - grupowanie zapytań

JMeter - grupowanie zapytań

Źródła

Tags: , ,