Na początku sprawdźmy jak wygląda orientacyjny transfer do serwerów ulokowanych w różnych miejscach Polski i świata. Sprawdzana była prędkość wysyłania, pobierania oraz czas odpowiedzi, czyli czas jaki zajmuje dotarcie sygnału do serwera testowego i powrót.
Prędkość pobierania i wysyłania
[Mb/s] więcej = lepiej
| Warszawa (3 ms) |  670 127 |
| Kraków (5 ms) | 412 61 |
| Szczecin (9 ms) | 395 65 |
| Londyn (42 ms) | 374 659 |
| Poznań (5 ms) | 275 120 |
| Gdańsk (5 ms) | 265 66 |
| Suwałki (26 ms) | 248 145 |
| Frankfurt (29 ms) | 218 92 |
| Moskwa (90 ms) | 112 292 |
| Nowy Jork (108 ms) | 95 8 |
| San Francisco (218 ms) | 23 29 |
| Melbourne (341 ms) | 18 9 |
| Hong Kong (316 ms) | 5 4 |
| Download Upload |
Wyniki są różne. Stały jest tylko spadek prędkości wraz ze wzrostem odległości do serwera testowego, co jest rzeczą normalną. Świetne są również czasy odpowiedzi Polskich serwerów. Oprócz tego trzeba dodać, że prędkości zależą przede wszystkim od chwilowego obciążenia. Uzyskane wyniki są średnimi wartościami uzyskanymi z trzech pomiarów wykonanych o różnych porach dnia. Czasem prędkość była niższa, a czasem, gdy obciążenie całej sieci malało notowaliśmy wartości bliskie nawet 900 Mb/s. W każdym jednak przypadku mamy zagwarantowaną minimalną prędkość 100 Mb/s, o ile oczywiście drugi serwer będzie w stanie wysłać taką ilość danych.
W drugim teście sprawdziliśmy jakość i stabilność łącza. Wykonaliśmy to przez zmierzenie dokładnych opóźnień do kilku polskich i zagranicznych serwerów. Bardziej istotny oprócz pingu, który zależy w dużej mierze od odległości jaką ma do pokonania sygnał, jest tak zwany jitter, czyli krótkookresowe odchylenie od ustalonych, okresowych charakterystyk sygnału. Duże jego wartości mogą oznaczać niską stabilność łącza. Sprawdzaliśmy również stopień utraty pakietów, który umieszczony został w nawiasie pod nazwą miasta.
Czas odpowiedzi i jitter
[ms] mniej = lepiej
| Białystok (0%) | 9 1 |
| Czechowice (0%) | 10 1 |
| Poznań (0%) | 14 4 |
| Opole (0%) | 19 1 |
| Dublin (0%) | 56 1 |
| Moskwa (0%) | 65 1 |
| Frankfurt (0%) | 67 3 |
| Waszyngton (0%) | 121 2 |
| Los Angeles (0%) | 184 2 |
| Sydney (0%) | 360 2 |
| Seul (0%) | 371 4 |
| Czas odpowiedzi Jitter |
Nie możemy absolutnie nic powiedzieć o czasach odpowiedzi. Są one uzależnione w dużej mierze od odległości od serwera. Na pochwałę zasługują zmierzone wartości jitter, które pokazują stabilność łącz danych serwerowni oraz utraty pakietów, gdzie wszystkie zawsze docierały na miejsce.
W kolejnym teście wykorzystaliśmy stronę http://host-tracker.com. Pozwala ona na sprawdzenie czasów dostępu uruchomionej na serwerze strony www z kilkudziesięciu serwerów ulokowanych w różnych miejscach świata. W wynikach nie zauważyliśmy żadnych podejrzanych wartości i w większości przydatków nasza witryna będzie ładować się błyskawicznie.
Przejdźmy do testów dysku twardego. Na początek skorzystaliśmy z aplikacji fio, czyli Flexible I/O Tester. Jest to bardzo rozbudowane narzędzie pozwalające na sprawdzenie wydajności pamięci masowej w różnych testach. My sprawdziliśmy odczyt i zapis (read i write), zarówno sekwencyjny jak losowy (random) z buforowaniem i bez (direct=1). Fio wykonuje testy na podstawie przygotowanych wcześniej plików konfiguracyjnych, którego przykładowa, wykorzystana w teście treść znajduje się poniżej.
[read-direct]
rw=read
size=1G
direct=1
directory=/tmp/
numjobs=1
group_reporting
name=read-direct
bs=4k
runtime=15
Dokładne znaczenie wszystkich parametrów można sprawdzić na przykład na tej stronie. W skrócie działaliśmy na próbce o rozmiarze jednego gigabajta, jednocześnie uruchomione było jedno zadanie, a wielkość bloku testowego wynosiła 4 KB. Oprócz tego aplikacja sprawdza również ilość IOPS, czyli ilość operacji wejścia/wyjścia, co zostało podane w nawiasie pod nazwą testu. Liczba wyraża jak wiele operacji we/wy, zarówno zapisu jak i odczytu, urządzenie może wykonać w ciągu jednej sekundy. Wartość ta różni się oczywiście w zależności od typu i charakterystyki wykonywanej operacji i jest ona bardzo ważna, ponieważ przykładowo na serwerze www częściej odczytywane są drobne pliki budujące strony internetowe, aniżeli duże archiwa, dlatego pamięć musi cechować się szybkim i jak najwydajniejszym do nich dostępem.
Prędkość dysku twardego
[MB/s] więcej = lepiej
| read-direct (50577 IOPS) | 202,3 |
| write-direct (161617 IOPS) | 646,4 |
| random-read-direct (222 IOPS) | 0,9 |
| random-write-direct (147853 IOPS) | 591,4 |
| read (45789 IOPS) | 183,1 |
| write (163737 IOPS) | 654,9 |
| random-read (230 IOPS) | 0,9 |
| random-write (146285 IOPS) | 585,1 |
Na koniec skorzystaliśmy z programu Bonnie++, który pozwala na zmierzenie prędkości dysku oraz przede wszystkim czasów dostępu. By uzyskane wyniki zapisać w wygodnej postaci strony HTML wpisaliśmy do konsoli umieszczone niżej zapytanie.
bonnie++ -m test-box -u root -x 3 -d /tmp/ -s 1024 -r 512 | bon_csv2html > result.html
Testy sieci wypadły bardzo dobrze. Połączenie dostępne dla naszego serwera stoi na bardzo wysokim poziomie. Bardzo wydajna jest również pamięć masowa. Zastosowanie w serwerach macierzy RAID10 powoduje osiąganie prędkości nawet 600 MB/s.
