W tym rozdziale opisuję testy, mające na celu ocenę wydajności aplikacji generowanych przez translator TLCC. Sprawdzają one szybkość działania poszczególnych elementów, które wchodzą w skład generowanych programów oraz porównują te wartości z osiągami istniejących systemów. Zmierzona została szybkość takich kluczowych operacji jak zapisywanie i odczytywanie trwałych obiektów, czy wywoływanie zdalnych metod przy pomocy biblioteki CORBA.
Wszystkie opisane w tym rozdziale testy zostały przeprowadzone na komputerze (lub kilku komputerach) Pentium II 350 MHz.
Przy ocenie wydajności przechowywania obiektów trzeba wziąć pod uwagę wpływ częstych modyfikacji danych na prędkość ich odczytu i zapisu. Obiekt poddany serializacji jest sekwencją bajtów, której długość może się znacząco zmieniać podczas pracy aplikacji. Dobrym przykładem są listy grup tematycznych, do których można dopisywać nowe elementy i przez to zwiększać rozmiar sekwencji, jakie powstają z obiektów w wyniku serializacji. Również w innych przypadkach dane przechowywane w serwisie WWW mają tendencję do zwiększania swojego rozmiaru. Dotyczy to np. wiadomości na forum dyskusyjnym lub różnych informacji związanych z konkretnym użytkownikem (im więcej działań wykonuje, tym więcej danych musi być zapamiętanych).
Celem testów opisanych w tym punkcie był pomiar prędkości odczytu i zapisu sekwencji bajtów, które często zmieniają swój rozmiar. Początkowo zostało utworzonych 5 000 sekwencji o rozmiarze 1 KB każda. Następnie losowo była odczytywana jedna z nich i powiększana o kolejny 1 KB. Dla porównania test ten został przeprowadzony także przy pomocy różnych istniejących systemów, umożliwiających przechowywanie danych. Testowane systemy to interpreter PHP (dane przechowywane były w sesjach) i baza danych MySQL (jedna z najszybszych baz danych).
Liczba 5 000 sekwencji została tak dobrana, aby ich łączny rozmiar w czasie testu przekroczył kilkukrotnie wielkość pamięci operacyjnej (64 MB). W przypadku większej pojemności pamięci komputera efekt otrzymany w teście można uzyskać poprzez proporcjonalne zwiększenie liczby obsługiwanych sekwencji.
Wyniki testów zostały zebrane w tabeli 6.1. Aby zilustrować ich przebieg wykonane operacje podzielono na równe grupy i dla każdej z nich podano średni czas obsługi sekwencji w milisekundach. Każda grupa obejmowała 10 000 operacji, dzięki czemu uzyskane dane w sposób zwięzły przedstawiają zmiany czasu wykonywania poszczególnych działań. Oto objaśnienie zawartości kolumn tabeli 6.1:
|
Tabela pokazuje, że początkowo dla wszystkich testowanych systemów czas obsługi sekwencji jest bardzo mały. Jest to spowodowane niewielką ilością danych, dzięki czemu mieszczą się one w pamięci, służącej jako bufor dla dysku. W pierwszej fazie testu moduł aplikacji TLCC jest trochę wolniejszy, co ma swoje źródło w szybkim wzroście rozmiaru pliku, który przechowuje te dane (później jego rozmiar nie zmienia się znacząco).
W dalszej części testu, gdy dane przestają się mieścić w pamięci, rozwiązania używające sesji PHP i bazy danych okazują się znacznie wolniejsze niż TLCC. Przyczyną tego jest fragmentacja sekwencji w plikach sesji PHP lub w bazie danych. Natomiast sekwencje w TLCC zapisywane są bez fragmentacji. Łagodny wzrost czasu obsługi w tym przypadku jest spowodowany przyrostem wielkości danych oraz koniecznością coraz częstszego przegrupowywania sekwencji w ramach sekcji (aby możliwe było wielokrotne użycie poszczególnych sekcji).
W przypadku testu oznaczonego jako DB 2 druga część wyników nie została umieszczona w tabeli ze względu na to, że testowanie trwałoby bardzo długo. Lecz już z częściowych rezultatów wynika, że jest to rozwiązanie zdecydowanie najmniej efektywne.
Tabela 6.2 przedstawia wyniki tego samego testu, ale zgrupowane według wielkości obsługiwanych sekwencji (kolumna SEKW.). Ich rozmiar podany jest w kilobajtach. Natomiast średni czas obsługi sekwencji o określonej długości został wyrażony w milisekundach.
|
Test pokazuje wyraźny związek między wielkością zapamiętywanych danych, a czasem ich obsługi. Widać również, że fragmentacja ma bardzo istotne znaczenie przy szybkości dostępu do informacji, których wielkość jest zmienna. W przypadku wielu modyfikacji sekwencje znacznie szybciej są obsługiwane przez aplikacje, generowane za pomocą translatora TLCC. Ostateczne uszeregowanie testowanych rozwiązań pod względem efektywności wygląda następująco: TLCC 2, TLCC 1, DB 1, PHP, DB 2.
W poprzednim punkcie została przetestowana obsługa sekwencji o zmiennej długości. Istnieją jednak przypadki podczas działania typowej aplikacji, że wielkość obiektów (po wykonaniu serializacji) pozostaje stała lub są to zmiany niewielkie.
Kolejny test miał na celu sprawdzenie szybkości obsługi sekwencji o stałej długości, przy użyciu porównywanych w tym rozdziale systemów. Polegał on na stworzeniu 20 000 jednostek informacji o rozmiarze 10 KB każda. Następnie program testujący przeprowadzał 40 000 odczytów, wybierając za każdym razem losową sekwencję. W drugiej części testu oprócz odczytu wykonywana była także modyfikacja i zapis losowej sekwencji. Jednak modyfikacja nie zmieniała jej rozmiaru. W tabeli 6.3 umieszczono uzyskane wyniki.
|
W przypadku oznaczonym jako PHP niemożliwe było uzyskanie wyłącznie odczytu sesji, ponieważ zapis zostaje wykonany automatycznie dopiero po zakończeniu skryptu. Również z tego powodu czas zapisu sekwencji nie został całkowicie uwzględniony w drugiej części testu (często podczas odczytu nowej sesji zbuforowane dane poprzednich sesji muszą być zachowane na dysku, więc zapis wpływa w pewnym stopniu na czas odczytu).
Z testu wynika, że osiągi wszystkich testowanych rozwiązań są bardzo zbliżone. W teście oznaczonym jako TLCC 2 czas obsługi sekwencji jest trochę krótszy, gdyż rozwiązanie to używa pliku o bardzo dużych sekcjach i niskim progu powtórnego użycia. Dzięki temu bardzo wiele sekwencji zapisywanych jest przy pomocy jednej operacji dostępu do dysku.
Aplikacja WWW obsługująca grupy tematyczne (opisana w rozdziale 5) pozwala sprawdzić rzeczywistą wydajność generowanych programów. Kluczowym czynnikiem, który wpływa na szybkość są operacje związane z systemem CORBA, takie jak wywoływanie zdalnych funkcji i transfer większych porcji danych przy pomocy tych wywołań. Podczas pracy aplikacji, serwer wyświetla na bieżąco informacje dotyczące czasu obsługi żądań.
W celu oceny rzeczywistej wydajności systemu przeprowadzono test, polegający na wykonaniu pewnej liczby operacji na zaimplementowanym serwisie. Były to: logowanie użytkownika, przeglądanie kategorii, dodawanie nowych grup, umieszczanie nowych wiadomości na listach dyskusyjnych itp. Aplikacja obsługiwała 4096 kategorii tematycznych, przy czym każda zawierała po 8 elementów. Test obejmował 500 żądań do serwera. Zmierzony został również czas operacji związanych ze zdalnym wywołaniem metod. Otrzymane wyniki są zebrane w tabeli 6.4.
|
Test przeprowadzono w sytuacji, gdy wszystkie procesy wchodzące w skład działającej aplikacji zostały uruchomione na tej samej maszynie. Uzyskane wyniki można zinterpretować w ten sposób, że aplikacja jest w stanie obsługiwać średnio 18 żądań w ciągu sekundy. Przy tym każde żądanie wymaga komunikacji z serwerem obiektów dzielonych i wizualizacji wielu obiektów. Rezultaty testów dostępne w sieci Internet wskazują, że typowa efektywność dla różnych aplikacji WWW waha się od kilku do kilkudziesięciu żądań na sekundę. Biorąc pod uwagę to, że testy takie obejmują żądania skierowane do jednej strony WWW (jej zawartość nie ulega zmianie), a opisywany w tym punkcie test dotyczy rzeczywistych akcji i całkowicie dynamicznie generowanych stron WWW, to otrzymane wyniki można uznać za zadowalające. Z testu wynika także, że narzuty związane z zastosowaniem systemu CORBA (chodzi tu o zdalne wywoływanie funkcji) są niewielkie i akceptowalne.
Został również przeprowadzony test, sprawdzający szybkość obsługi użytkowników w środowisku rozproszonym. Polegał on na wysyłaniu równocześnie do aplikacji dużej liczby żądań, przez specjalny program testujący. Uruchamianych było wiele instancji programu testującego, z których każda w losowy sposób poruszała się po drzewie kategorii i wybierała pozycje z głównego menu (wysyłając odpowiednie żądania HTTP do serwera).
Test wykonywał się na drzewie grup, które składało się z 4096 elementów (każda grupa posiadała 8 elementów potomnych). Początkowo na jednym komputerze działał serwer główny, serwer obiektów dzielonych i serwery obiektów (dla sesji). W teście dla większej liczby komputerów serwery obiektów zostały przeniesione na te nowe maszyny. We wszystkich przypadkach obsługa żądań wysyłanych przez program testujący rozkładała się równomiernie między wszystkie uruchomione serwery obiektów.
Tabela 6.5 przedstawia opis testowanych konfiguracji dla podanej liczby komputerów. Każdy komputer otrzymał numer, który go identyfikuje. Opis konfiguracji to lista procesów, działających na poszczególnych maszynach. Oto objaśnienie skrótów:
|
Dla każdej testowanej konfiguracji mierzona była liczba obsłużonych żądań w ciągu sekundy. Otrzymane wyniki zawiera tabela 6.6.
|
Z zestawienia wynika, że w początkowej fazie testu aplikacja dobrze
się skaluje. Jednak przy dodawaniu kolejnych serwerów obsługujących
obiekty użytkowników, serwer obiektów dzielonych staje się wąskim
gardłem. Dlatego dalsze skalowanie aplikacji wymaga uruchomienia większej
liczby serwerów obiektów dzielonych![[*]](footnote.png)
.
W rozdziale zostały opisane testy, których zadaniem było porównanie wydajności aplikacji WWW tworzonych przy pomocy standardowych narzędzi oraz aplikacji generowanych przez translator TLCC. Kluczowymi elementami, które wpływają na prędkość obsługi żądań przez programy napisane w TLCC są: efektywność przechowywania trwałych obiektów oraz narzuty związane z wykorzystaniem systemu CORBA. Testy wykazały, że mechanizmy te są efektywne i nadają się do użycia w aplikacjach WWW. Ponadto w zastosowaniach, które wymuszają częste zmiany wielkości przechowywanych danych (takich jak grupy tematyczne), rozwiązanie wykorzystujące TLCC jest szybsze od bazy danych.
W końcowej części rozdziału został opisany test, przeprowadzony z rzeczywistą aplikacją, napisaną w TLCC. Potwierdził on, że system ten nadaje się do tworzenia sprawnie działających serwisów WWW.