Mateusz Kozak – weblog

Tworząc serwisy nastawione na spory ruch (800-900 tysięcy odsłon dziennie) z duża ilością mocno zmieniającego się kontentu, administrator serwera na którym się ów serwis znajduje ma nie lada problem do rozwiązania.

Zaiste, gdy load average serwera z procesorem Intel Core2Duo o taktowaniu rzędu 2GHz z 8GB ramu i terabajtowym storagiem w postaci raidu osiąga ponad 120, czy nawet ponad 200, ewidentnie coś musi być nie tak.

W dzisiejszych czasach, gdy domowe stacje robocze posiadają grubo ponad 1GB pamięci (średnio pewnie koło 3GB),  4 rdzeniowe procesory (Intel Quad2Core czy AMD Phenom),  nie wspominając o maszynach stricte serwerowych, tak naprawdę wąskim gardłem są przepustowości jakie oferują nam dyski twarde (i wiem, że ameryki tutaj nie odkryłem)
Zdecydowanie większość serwerów dedykowanych jakie są obecnie stosowane przy hostowaniu wszelkich stron WWW posiada dyski na interfejsie SATA-2. Co jednak w sytuacji, gdy te 70 czy 80MB/s jest mocno niewystarczające?
Są dyski SAS (Serial Attached SCSI), które są trochę szybsze, czy SSD (które wszystkie obecne rozwiązania biją na głowę), jednak za 140GB dysk SAS zapłacimy około 900zl, SSD też nie są tanie. Jest jednak lekarstwo i na ten problem.

Pamięć RAM w chwili obecnej kosztuje grosze, ładując więc do serwera 8, 16 czy nawet 32 GB tego rodzaju „nośnika” danych (który będzie służył i tak tylko tymczasowemu ich przechowywaniu ) możemy dużo zaoszczędzić.

Jak więc zmniejszyć obciążenie maszyny, wykorzystać dostępną pamięć operacyjną, oraz przyspieszyć proces ładowania się stron?
Serwer httpd (załóżmy najpopularniejszy obecnie Apache), przy każdym requeście odczytuje plik jakiego żąda klient. Jeżeli do jednego pliku odnosi się 50 czy 100 requestów jednocześnie, plik jest odczytywany z dysku właśnie tyle razy, czyste marnotrastwo zasobów. A co gdyby klient łączył się z oprogramowaniem, które sprawdzi czy dany plik nie był już wysyłany w ostatnim czasie? (powiedzmy 1 minuty) Jeżeli plik nie znajdował by się w pamięci operacyjnej systemu, bądź istniał tam, a na dysku znajdowała by się jego zmieniona wersja, byłby odczytywany z dysku i do niej wrzucany. Przy kolejnym odpytaniu o ten plik, nie czytamy go już z dysku, a jedynie wysyłamy prosto z pamięci operacyjnej. Dzięki temu zmniejsza się liczba odwołań do dysku, apache zużywa mniej zasobów, a pamięć RAM (której w serwerach zazwyczaj wiele z czego większosć nie wykorzystana)  znalazłaby wykorzystanie.

Do tego celu służy takie oprogramowanie jak  squid w trybie reverse-proxy (który jednak do najlżejszych nie należy i którego nie polecam, jednak wypada o nim wspomnieć), moduł mod_mem_cache w Apache, czy dedykowany do takiego właśnie zastosowania varnish.

Cache’ować w ten sposób możemy pliki, których jest dużo, są małe, i zwiększają zapotrzebowanie na I/O dysku (obrazy jpg,png,gif, pliki css czy javascript, a nawet lekkie swf), nie polecam za to serwowania w ten sposób danych wynikowych plików php, gdyż zbyt często się zmieniają (w końcu mówimy tutaj o serwisach ze sporym ruchem i dużą ilością danych).

Skoro jesteśmy już przy kwestii cache, warto wspomnieć, że można w ten sposób również odciążyć serwery bazodanowe, w końcu to one zazwyczaj są najbardziej obciążone. Po co mamy odwoływać się za każdym razem bezpośrednio do MySQL’a, jeżeli wyniki zwracane przez zapytania (_zwracane_, nie bierzemy pod uwagę danych wprowadzanych) pozostają  bez zmian przez jakiś okres czasu (nawet jeśli jest to 30 sekund). Do tego celu służy genialne wręcz narzędzie o nazwie memcache, od strony administratora wystarczy instalacja daemona memcached, bibliotek do jego obsługi, krótka konfiguracja całości, a resztę pozostawiamy programistom. Z moich obserwacji wynika, że implementacja w kodzie obsługi tego mechanizmu keszowanie nie jest zbyt wielkim problemem.

Całość tekstu poparta jest moimi własnymi doświadczeniami. Dzięki zastosowaniu opisanych mechanizmów load spadł z ponad 100 do max 15 w godzinach największej oglądalności (Core2Duo 2GHz, 8GB ram, 2 dyski 500GB w RAID0), a czas ładowania się strony spadł z 20-30 sekund do 6 sekund. Na przykładzie szafa.pl