Wyświetlenie parametrów Javy

Maszyna wirtualna Javy pozwala na ustawienie wielu różnych parametrów podczas uruchamiania, które moją wpływ na jej działanie. Pozwalają one m.in. na optymalizację pracy GC czy też związane z wielkością zajmowanej pamięci.

Jednym z parametrów jest AggressiveOpts, który pozwala na włączenie różnych parametrów optymalizacyjnych, które mogą zostać włączone w kolejnym wydaniu JVM. Warto jednak pamiętać, że wraz z każdym wydanie JVM lista tych opcji może się zmienć a ciężko znaleźć informację, jakie parametry są aktualnie używane.

Z pomocą tutaj przychodzą dwie opcje JVM:

  • PrintFlagsFinal – pozwala ona na wyświetlenie wartości wszystkich dopuszczalnych opcji
  • UnlockDiagnosticVMOptions – daje dostęp do dodatkowych opcji konfiguracyjnych

I tak listę wszystkich parametrów wraz z ich wartościami można obejrzeć przy pomocy polecenia:

java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version

A lista dla włączonej optymalizacji AggressiveOpts:

java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version

Lista jest dosyć spora, więc prościej będzie zobaczyć po prostu różnice pomiędzy uruchomieniem JVM z i bez parametru AggressiveOpts:

diff <(java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version ) \
   <(java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version )

W wersji JVM 1.6.26 wyświetli listę 6 różnych opcji, których ustawienie się różni. Łatwo także sprawdzić, czym się różni uruchomienie JVM z parametrem server oraz bez.

Dla ułatwienia analizy różnic, zamiast polecenia diff można użyć np. vimdiff:

vimdiff <(java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version ) \
   <(java -XX:+AggressiveOpts -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version )

Źródła

Tags: ,

Instalacja Oracle Javy w Ubuntu Natty (11.04)

Standardowo w Ubuntu Java w wersji od Oracla (czyli dawana Sunowska) jest dostępna w repozytorium partner. Jednak w przypadku Ubuntu Natty (w wersji alfa) niestety jej tam jeszcze nie ma, prawdopodobnie zostanie umieszczona już po premierze wersji stabilnej. Na szczęście, łatwo można ją zainstalować przy wykorzystaniu dodatkowych repozytoriów, wystarczy wydać polecenie:

sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update

I zainstalować Javę:

sudo apt-get install sun-java6-jdk

Tags:

Instalacja lokalnego pakietu w połączeniu z rozwiązywaniem zależności (polecenie gdebi)

Jedną z bardziej irytujących rzeczy podczas instalacji nowego pakietu przy użyciu polecenia dpkg jest brak rozwiązywania zależności. Powoduje to, że zamiast zainstalować pakiet musimy ręcznie doinstalowywać pakietu z repozytorium.

Brakuje możliwości takiej instalacji pakietu jak robi to polecenie yum:

yum localinstall nazwa_pakietu.rpm

Polecenie to zainstaluje wybrany pakiet jednocześnie rozwiązując zależności przy użyciu dostępnych repozytoriów.

Użycie polecenia dpkg może wyglądać następująco (próba instalacji Picasy w Ubuntu):

# dpkg -i picasa_3.0-current_amd64.deb
Zaznaczenie poprzednio niezaznaczonego pakietu picasa.
(Odczytywanie bazy danych ... 299273 files and directories currently installed.)
Rozpakowanie picasa (z picasa_3.0-current_amd64.deb) ...
dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie picasa:
 picasa zależy od libc6-i386 (>= 2.2); jednakże:
  Pakiet libc6-i386 nie jest zainstalowany.
 picasa zależy od ia32-libs; jednakże:
  Pakiet ia32-libs nie jest zainstalowany.
 picasa zależy od lib32asound2; jednakże:
  Pakiet lib32asound2 nie jest zainstalowany.
 picasa zależy od lib32z1; jednakże:
  Pakiet lib32z1 nie jest zainstalowany.
dpkg: błąd przetwarzania picasa (--install):
 problemy z zależnościami - pozostawiony nieskonfigurowany
Przetwarzanie wyzwalaczy dla gconf2...
Wystąpiły błędy podczas przetwarzania:
 picasa

W przypadku dystrybucji opartych o Debiana można użyć polecenia gdebi. Pozwoli ono na zainstalowanie pakietu i jednoczesne rozwiązanie jego zależności. Instalacja Picasy przy użyciu tego narzędzia wygląda tak:

# gdebi picasa_3.0-current_amd64.deb
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Building data structures... Done
Building data structures... Done  
Wymaga instalacji poniższych pakietów:
ia32-libs  lib32asound2  lib32bz2-1.0  lib32gcc1  lib32ncurses5  lib32stdc++6  lib32v4l-0  lib32z1  libc6-i386
Image management application from Google
 Picasa is software that helps you instantly find, edit and share all

Jak widać od razu zostaje zaprezentowana lista dodatkowych pakietów do instalacji, jak się zgodzimy na ich instalację to zostaną pobrane i zainstalowane.

Źródła

Tags: , ,

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: , ,