Opis testów

Tablica: Przedstawia rozkład ilości plików wykorzystanych w teście nr 3 ze względu na ich rozmiar

rozmiar	ilość
<3MB, 1MB>	20
(1MB, 500KB>	8
(500KB, 250KB>	9
(250KB, 100KB>	45
(100KB, 50>	58
(50, 25>	71
(25, 14>	75
(14, 8>	774

Przeprowadziłem siedem testów:

1. Odczytanie 160 plików każdy po 50KB.
2. Odczytanie jednego 8 MB pliku.
3. Odczytanie 1060 plików rozmiaru od 8KB do 3MB. W sumie pliki te mają 52MB. Rozkład liczby plików ze względu na ich rozmiar przedstawia tablica 10. Jest to zbiór plików, z których korzystał system XWindows w ciągu kilku minut swojej pracy.
4. Kopiowanie plików z pkt 3. na dysk, na którym jest schowek.
5. Wykonanie na każdym z plików z pkt. 3 zadania silnie obciążającego procesor (utworzenie pliku tar.gz z plików z pkt. 3).
6. Wykonanie operacji zawsze powodujących odwołanie się do pełnego schowka nie posiadającego żądanych danych.
7. Wykonanie wielu następujących po sobie operacji odczytu i zapisu wykonanych na tym samym pliku. Prawdopodobieństwo wykonania operacji zapisu wynosi , a operacji odczutu .

Celem dwóch pierwszych testów jest sprawdzenie efektywności schowka, gdy wykonywane są tylko operacje odczytu danych. Chciałem także sprawdzić, jak rozmiar odczytywanego pliku ma wpływ na działanie schowka oraz jak duży wpływ na czas działania ma walidacja plików. W teście nr 1 walidacja odbywa się 160 razy (dla każdego pliku), a w teście nr 2 walidacja występuje raz (jest tylko jeden plik).

Celem testu nr 3 jest sprawdzenie efektywności schowka działającego na rzeczywistych danych składających się z wielu plików różnego rozmiaru.

Test nr 4 po odniesieniu do testu nr 3 umożliwia sprawdzenie, w jaki sposób zwiększenie aktywności dysku zawierającego schowek wpływa na efektywność schowka.

Celem testu nr 5 jest sprawdzenie wydajności schowka w momencie silnego obciążenia procesora stacji klienckiej.

Test nr 6 służy do sprawdzenia, jak duże obciążenie powoduje schowek, który nigdy nie realizuje żądania i dodatkowo obciąża stację kliencką przez ciągłe usuwanie nieaktualnych danych ze schowka. Jest to najbardziej pesymistyczny przypadek, gdy schowek zawsze opóźnia wykonanie zadania.

Test nr 7 służy do symulacji rzeczywistej sytuacji, w której operacje odczytu występują 6 razy częściej niż zapisu.

Niestety nie mogłem wykonać testów, porównujących moje rozwiązanie z rozwiązaniem Grega Badrosa. Po pierwsze, jego wersja opiera się na jądrze 2.0. Jądo w wersji 2.2 ma efektywniej zaimplementowaną wirtualną przestrzeń plików. Nawet dwie identyczne optymalizacje NFS dawałyby różne wyniki w zależności od wykorzystanego jądra. Po drugie kompilacja rozwiązania Grega Badrosa jest niemożliwa z powodu błędów, jakie się podczas niej pojawiają.

Aby odnieść się do rozwiązania Grega Badrosa, mógłbym porównywać wykonane przez niego testy z moimi testami. Tu z kolei pojawia się problem niejasnych lub niewiarygodnych testów. Przykładem są dwa wykonywane po sobie testy, gdzie zostaje odczytany 6,1MB plik. Przy pierwszym odczycie czas dostępu wynosi około 0,6 czasu dostępu standardowego NFS. Jest także mniejsza niż w standarodowym systemie NFS ilość komunikatów RPC obługujących fukcję read. Przy drugim odczycie czas dostępu wynosi około 0,1 czasu dostępu oryginalnego NFS. Nie jest powiedziane, czy seria tych dwóch testów jest wykonana raz czy wiele razy (w tym przypadku podany czas były średnią czasów wielu testów). Gdyby testy był wykonane jeden raz, to przy teście pierwszym, niemożliwe byłoby osiągnięcie mniejszej ilości komunikatów RPC¹⁴ względem standardowego NFS. Gdyby był wykonywany wiele razy, to schowek byłby rozgrzany i czas dostępu w pierwszym i drugim przypadku byłby taki sam¹⁵.