Inne testy

Test opracowany przez InfoWorld nie był pierwszą próbą pomiaru wydajności Javy na serwerze. Przeprowadzony wcześniej test VolanoMark 1.0 (firmy Volano) symuluje pogawędki przez sieć z dużą liczbą sesji połączeniowych między wieloma jednocześnie dołączonymi klientami. InfoWorld posłużył się jednak testem, który symuluje warstwę serwera aplikacyjnego, zapewniającego dostęp do danych i logikę działania aplikacji dla stosunkowo dużej liczby "chudych" klientów. Sprawdzono też, jak pojedyncza maszyna wirtualna radzi sobie z obsługą dużej liczby wątków, symulujących żądania dostępu do danych od klientów.

Testowano systemy za pomocą aplikacji klient/serwer, służącej do obsługi biura maklerskiego; zawierała ona typowe transakcje, zapytania do bazy i wykonywanie raportów. Po stronie klienta aplikacja była bardzo mała - jej funkcje ograniczały się do: ustanowienia połączenia przez gniazdko (socket); wysyłania do serwera niewielkiego zapytania i odbierania odpowiedzi, mających postać łańcuchów znakowych; liczenia zakończonych zapytań. W aplikacji klienta wymuszano proporcje pięciu transakcji, trzech zapytań i jednego raportu. Wartości te można było zmieniać, ale nie testowano zmian wydajności po zmianie proporcji. Wybrano czasowe okno testowania równe 7 min, ale odrzucano wyniki w pierwszych dwóch minutach przeznaczonych na wystartowanie dostatecznej liczby klientów. Odliczaniem czasu zajmował się serwer, podczas gdy stacje klienta obliczały liczbę operacji zakończonych w 5-minutowym okienku. Dodano liczbę transakcji, zapytań i raportów, i po podzieleniu przez 5 otrzymano wynik, określany na wykresach umowną nazwą "transakcji/min".

Początkowe uruchomienie testu polegało na wystartowaniu jednego wątku klienta i serwera. Następnie każdy klient startował 30 wątków; potem dodawano dalszych klientów, aby móc zbierać dane w etapach co 30 wątków, przesyłając zapytania i odpowiedzi przez to samo gniazdko. Jak wykazały testy profilowania aplikacji, takie połączenie nie powodowało opóźnień w pracy. Ponieważ nie było pewności, że łącze Ethernet 100BaseT będzie dostatecznie szybkie, uruchomiono program serwera i klienta na tej samej maszynie. Zakodowano również "na sztywno" odpowiedzi na zapytania do raportów w postaci wektorów i macierzy, aby wydajność bazy nie miała wpływu na test wydajności.

To podejście ma zalety i wady. Z jednej strony, uruchamianie części aplikacji dla klienta i serwera na jednej maszynie zaciemnia względny wpływ tych części na wydajność. Z drugiej, serwer ma największy wpływ na wydajność systemu, gdyż musi na nim działać liczba wątków równa sumie wątków u wszystkich klientów, a wątek serwera ma znacznie większą pracę do wykonania niż wątek klienta.

Za przyjętą metodą testowania przemawia dodatkowy argument. Pozwala ona bowiem testować złożony i realistyczny system, w którym działa wiele maszyn wirtualnych o różnej liczbie wątków każda. Ponieważ korzystano z tej samej maszyny wirtualnej dla części klienta i serwera (z wyjątkiem przypadków, gdy użyto aplikacji skompilowanej do kodu maszynowego), pomiary wskazują dość dobrze wydajność maszyn wirtualnych każdego z producentów. Testując IBM-owski kompilator do kodu maszynowego (High Performance Compiler for Java v. 12 - HPCJ), użyto IBM JDK dla AIX na serwerze i IBM JDK dla Windows NT jako klienta. Natomiast testując aplikacje kompilowane dla serwera przez Symantec Visual Cafe Database Development Edition 2.5, użyto Sun Solaris JDK jako stacje klienta.

Na systemie Sun Solaris trzeba było ograniczyć maksymalny rozmiar sterty (heap) dla maszyny wirtualnej. Bez tego system nie działał. Podobne ograniczenia wprowadzono dla innych maszyn wirtualnych, z wyjątkiem maszyny Microsoftu, która nie pozwala na wprowadzanie tego parametru. Wyłączono również asynchroniczne usuwanie obiektów i klas z pamięci (garbage collection), aby przekonać się, czy zwiększa to wydajność; nie można było tego wykonać w maszynie wirtualnej Microsoft. Dla porównania testowano również maszyny wirtualne bez zadawania im rozmiarów pamięci i wyłączania usuwania obiektów i klas. W każdym z przypadków (znów z wyjątkiem Microsoftu) ograniczano rozmiar sterty dla maszyny wirtualnej klienta do 4 MB i wyłączano usuwanie obiektów i klas. Wyniki testów są przedstawione na wykresach.

Przyglądając się wynikom trzeba pamiętać, że pozioma kreska oznacza faktycznie rosnący czas odpowiedzi dla klienta, gdyż rośnie liczba wątków. Stały czas odpowiedzi był pokazany na wykresie jako ukośna linia rosnąca o stałym nachyleniu. W każdym z przypadków czas odpowiedzi zaczyna rosnąć po przekroczeniu ok. 90 wątków.