Apache jest stabilnym i wydajnym serwerem stron internetowych, którego największą wadą jest apetyt na pamięć RAM. Co w połączeniu z ciągle wzrastającą liczbą funkcji mojego serwerka (np. backup gmaila, centralka doświadczalnego monitoringu, repozytorium svn, bramka proxy domowej sieci) o dość ograniczonych zasobach może utrudnić komfortowe przeglądanie bloga przy większym ruchu.

Ile powinienem wymagać od skromnego serwerka chodzącego na procesorze oddającym niecałe 3W ciepła? Domyślam się, że w czysto teoretycznych sytuacjach typu ‘wykop effect‘ (maksymalnie ok 3-4tys odsłon na godzinę) i tak nie byłby w stanie długo wytrzymać ze względu na ograniczone możliwości wysyłowe mojego łącza. Przeprowadzając testy wydajności narzędziem ab założyłem równoczesne odwiedzanie strony głównej mojego wordpressowego bloga przez 20 użytkowników. Test oczywiście wykonałem z innej maszyny (z sieci lokalnej – podczas testu nie uwzględniam możliwości mojego łącza, gdyż te z pewnością byłyby niższe niż zdolność mojego atomu do serwowania stron).

robert@rob:~$ ab -c 20 -n 200 http://atom/

Przed optymalizacją takie obciążenie sprawiało, iż apache pożerał większość dostępnej pamięci RAM. Jasno widać, że szału nie ma – nie trzeba być wróżką, aby przewidzieć, że mój mały serwerek w przypadku zwiększonego ruchu nie wytrzyma kondycyjnie i najzwyczajniej się zatka.

Odchudzanie apache pod wordpressa

Optymalizację przeprowadzam zgodnie z poradnikiem theme foundry.

Wyłączamy niepotrzebne moduły apache

Ograniczając ilość ładowanych modułów do niezbędnego minimum zmniejszamy apetyt apache na pamięć, a co za tym idzie zmniejszamy szanse na konieczność wykorzystania dyskowego cache’u (mój serwerek ma tylko 1GB pamięci ram i wolny dysk!).

Moduły niezbędne do funkcjonowania wordpressa to:

LoadModule authz_host_module modules/mod_authz_host.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so

Wszystkie inne wyłączamy znakiem komentarza na początku wiersza. Autor poradnika z którego korzystam zaleca odkomentowanie modułu modnegotiation.so jeśli serwujemy wielojęzykowe treści. W przeciwnym przypadku trzeba zakomentować także wiersze:

LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW

ForceLanguagePriority Prefer Fallback

Dostrojenie modułu MPM Prefork

Domyślne ustawienia tego modułu ponoć sprawdzają się bardzo dobrze w przypadku bardzo dużego obciążenia… ale ja zamiast xeona mam na pokładzie atoma, dlatego ten moduł powinienem dostroić do możliwości mojego sprzętu – co powinno przynieść wzrost wydajności. Informacje o tym jak najlepiej wyliczyć poniższe parametry znajdziesz w źródle, z którego korzystałem.

StartServers 3
MinSpareServers 3
MaxSpareServers 10
ServerLimit 50
MaxClients 50
MaxRequestsPerChild 2000

Skrócenie czasu obsługi żądania

Domyślnie wordpress utrzymuje proces obsługujący każde zapytanie przez 15 sekund. Tutaj autor zaleca eksperymentalne obniżenie wartości zmiennej

KeepAliveTimeout  15

do niskiej wartości, np

KeepAliveTimeout 2

oraz równoczesne zwiększenie wartości zmiennej

MaxKeepAliveRequests 100

np. do

MaxKeepAliveRequests 200

Dostrojenie time-out’u

Zmienna TimeOut określa jak dużo czasu apacz powinien poświęcić na przyjmowanie pojedynczego zgłoszenia oraz odesłanie odpowiedzi. Obniżenie wartości parametru

Timeout 60

do

Timeout 30

powinno obniżyć podatność serwera na ataki DDOS, lub użytkowników z wolnymi łączami internetowymi, którzy szybko zajmą wszystkie wolne sloty.

Czy tak prosty proces dostrajania konfiguracji apacha dużo zmienił? Zmienił zadziwiająco dużo – optymalizacja ustawień serwera pozwoliła znacząco obniżyć wykorzystanie pamięci RAM – prawie 10%. Może nie jest to dużo, ale w przypadku ograniczonych zasobów każdy wolny megabajt się przyda.

Czy pamięciochłonność apache była jedynym czynnikiem wpływającym na szybkość obsługiwania zapytań? Powolność serwowania stron potęgowana była wolnym dyskiem netbooka, z którego apache odczytuje pliki i na którym zapisuje logi… jak sobie z tym fantem poradziłem? Napiszę niebawem.