W homecloud nie znajdziemy konkretnych pakietów, ponieważ sami decydujemy z czego korzystamy. My przygotowaliśmy trzy przykładowe konfiguracje serwerów Pro Cloud i sprawdziliśmy jak różnią się wydajnością. Konfiguracje naszych testowych serwerów Pro Cloud przedstawiamy poniżej.
| Serwer-1 | Serwer-2 | Serwer-3 | |
| Liczba rdzeni | 1 | 2 | 4 |
| Częstotliwość CPU | 1000 MHz | 2000 MHz | 2000 MHz |
| Miejsce na dysku | 40 GB | 40 GB | 40 GB |
| Pamięć RAM | 1024 MB | 2048 MB | 4096 MB |
| Pełna wirtualizacja | Nie | Nie | Nie |
| Autoskalowanie | Nie | Nie | Nie |
| Przepustowość | 100 Mb/s | 100 Mb/s | 100 Mb/s |
| Ilość adresów IPv4 | 1 | 1 | 1 |
| Szacunkowy koszt za miesiąc (netto) | 54,72 zł | 100,80 zł | 181.44 zł |
Na każdym serwerze zainstalowany został system CentOS w wersji 6, architektura X86_64. Dodatkowo zainstalowaliśmy Apache 2.2.15, MySQL 5.1.73 oraz PHP 5.3.3. Środowisko graficzne KDE zostało zainstalowane na końcu, gdy było to niezbędne. Jako stronę testową wykorzystaliśmy WordPress z domyślnym stylem. Wyniki są uśrednione, ponieważ wykonywaliśmy kilka pomiarów w różnych godzinach.
UnixBench
Pierwszy test wykonaliśmy z użyciem UnixBench, jest to popularne narzędzie do testowania wydajności komputerów z systemem Linux. UnixBench wykonuje automatycznie kilka pomiarów, bez potrzeby definiowania parametrów lub zmieniania ustawień.
Poniżej zamieściliśmy listę testów, które zostały wykonane podczas pracy narzędzia:
- Dhrystone 2 using register variables – zestaw instrukcji testujących operacje na liczbach stałoprzecinkowych
- Double-Precision Whetstone – podobnie jak powyżej, jednak w tym przypadku testowane są operacje na liczbach zmiennoprzecinkowych
- Execl Throughput – sprawdzenie maksymalnej ilości wywołań execl w ciągu sekundy
- File Copy 1024/256/4096 bufsize 2000/500/8000 – kopiowanie plików o różnych wielkościach przy różnych rozmiarach bufora
- Pipe Throughput – sprawdzanie ile razy w ciągu sekundy da się zapisać i odczytać próbkę o wielkości 512 bitów do określonego kanału komunikacyjnego
- Pipe-based Context Switching - mierzy ile razy dwa procesy mogą wymienić się inkrementowaną liczbą całkowitą poprzez określony kanał komunikacyjny w ciągu sekundy
- Process Creation – test ile procesów można utworzyć i zabić w określonym czasie
- Shell Scripts (1/8 concurrent) – sprawdzenie ile skryptów shell serwer może uruchomić i zamknąć w czasie jednej minuty
- System Call Overhead – szacuje czas potrzebny na wejście i opuszczenie jądra systemu poprzez ciągłe wywoływanie funkcji pobierającej numer procesu
[punkty] więcej = lepiej
| Dhrystone 2 using register variables |  913 3502 6127 |
| Double-Precision Whetstone | 550 1050 1844 |
| Execl Throughput | 408 1366 2348 |
| File Copy 1024 bufsize 2000 maxblocks | 579 859 722 |
| File Copy 256 bufsize 500 maxblocks | 416 535 592 |
| File Copy 4096 bufsize 8000 maxblocks | 792 1646 1725 |
| Pipe Throughput | 463 1712 3029 |
| Pipe-based Context Switching | 224 814 1401 |
| Process Creation | 392 1112 1824 |
| Shell Scripts (1 concurrent) | 425 1364 2501 |
| Shell Scripts (8 concurrent) | 406 1480 2538 |
| System Call Overhead | 496 1388 1695 |
| Wynik ogólny | 476 1263 1852 |
| Serwer-1 Serwer-2 Serwer-3 |
Tak jak można było się spodziewać, serwer o najmocniejsze konfiguracji osiągnął w przypadku większości testów najwyższe wyniki. Różnice pomiędzy serwerami są znaczne.
ApacheBench
ApacheBench zostało stworzone do wykonywania testów wydajnościowych serwerów HTTP. Jego zadaniem jest wydawanie powtarzających się żądań do określonego serwera. Nazwa może sugerować, że jest przeznaczony wyłącznie do testowania serwera Apache, jednak bezproblemowo możemy sprawdzić inne rozwiązania.
Test został wykonany z innego serwera, ilość zapytań ustawiliśmy na 1000, jednocześnie było wydawane maksymalnie 5 żądań. Poniżej prezentujemy komendę wykonującą testy.
ab -n1000 –c5 adres-strony
mniej = lepiej
| Całkowity czas | 378 s 98 s 96 s |
| Średni czas wykonania jednego żądania | 1591 ms 592 ms 481 ms |
| Serwer-1 Serwer-2 Serwer-3 |
Generowanie dużego obciążenia
Skorzystaliśmy z usługi LoadImpact, aby sprawdzić jak serwery radzą sobie podczas dużego obciążenia. Przeprowadzony test trwał 30 min, w tym czasie obciążenie rosło od 0 do 1000 tzw. wirtualnych użytkowników. Test został przeprowadzony z jednego serwera zlokalizowanego w Dublinie. Zależność czasu ładowania strony od ilości aktywnych użytkowników przestawiana jest na wykresie (niżej kolejno serwer 1, 2 oraz 3).
Tutaj również nie ma zaskoczeń, najmocniejszy serwer poradził sobie najlepiej. Czasy odpowiedzi najczęściej są w rozsądnych granicach, biorąc pod uwagę dość duży ruch. Natomiast należy tutaj pamiętać o wpływie konfiguracji na wydajność. W rzeczywistym środowisku bez większych problemów można dokonać optymalizacji i znacznie zmniejszyć czas ładowania (oczywiście do tego celu przydatne są logi serwera i dokładna analiza ruchu). Warto przypomnieć, że usługa Pro Cloud umożliwia skorzystanie z automatycznego skalowania (omawianego wcześniej), jego konfiguracja również może zapewnić czasy dostępu na niskim poziomie nawet przy bardzo dużym ruchu.
HardInfo
Ostatnie testy zostały przeprowadzone za pomocą aplikacji HardInfo. Dostarcza ona informacji o maszynie, na której została uruchomiona (procesor, RAM, karta sieciowa itp.). Dodatkowo posiada kilka testów wydajnościowych. Większość wyników przedstawia czas szyfrowania pewnej próbki danych z wykorzystaniem różnych technologii, który im jest krótszy tym lepszy.
| CPU Blowfish [sek] mniej = lepiej | 32,29 8,51 4,81 |
| CPU CryptoHash [MB/s] więcej = lepiej | 45,67 119,41 232,45 |
| CPU Fibonacci [sek] mniej = lepiej | 6,66 3,07 2,99 |
| CPU N-Queens [sek] mniej = lepiej | 15,61 15,86 17,94 |
| FPU FFT [sek] mniej = lepiej | 15,98 3,67 1,54 |
| FPU Raytracing [sek] mniej = lepiej | 56,11 31,45 29,54 |
| Serwer-1 Serwer-2 Serwer-3 |
