Porównanie optymalizatorów PHP - eAccelerator, PHP APC, XCache

Przez pewien czas korzystałem z eAcceleratora do przyspieszenia działania stron pisanych w PHP’ie ale czasem bywał niestabilny. Aktualizacje pojawiały się rzadko a od czasu do czasu miewałem problemy ze stabilnością tej wtyczki na kilku bardziej skomplikowanych aplikacjach. Zdarzało się że pomimo zmiany kodu w skrypcie php, eAccelerator serwował wciąż stary plik - konieczny był restart Apache’go by wszystko działało jak trzeba.

Zacząłem szukać alternatywy i trafiłem na dwa moduły:

• APC  (czyli Alternative PHP Cache), który ma być nawet domyślnie wbudowany w PHP od wersji 5.4,
• XCache  - projekt rozwijany przez jednego z programistów lighttpd.

Byłem ciekaw wydajności poszczególnych rozwiązań względem siebie, więc przygotowałem małe środowisko testowe składające się z 4 maszyn wirtualnych (działających pod kontrolą VirtualBox’a):

1. Apache 2.2 + PHP 5.3
2. Apache 2.2 + PHP 5.3 + eAccelerator 0.9.6.1 (instrukcja instalacji tutaj  )
3. Apache 2.2 + PHP 5.3 + APC 3.1.3p1 (pod Debianem paczka php-apc)
4. Apache 2.2 + PHP 5.3 + XCache 1.3.0 (pod Debianem paczka php5-xcache)

Najpierw przygotowałem pierwszą maszynę wraz z konfiguracją MySQL’a i domyślną instalacją WordPress’a 3.2 by test był w miarę miarodajny. Kolejne maszynki to klony tej pierwszej, plus zainstalowane i domyślnie skonfigurowane kolejne rozszerzenia. Każdemu z rozszerzeń przyznałem 32 MB pamięci na cache.

Metodyka testu

Do automatyzacji testu posłużył mi skrypt w bash’u uruchamiający ab dla 1000 zapytań z kolejno rosnącą liczbą równoległych połączeń. Pozwoli to na porównanie wydajności optymalizatorów przy mniejszym i większym obciążeniu. Uruchomienie testu dla czystej instalacji bez dodatku pokaże jak duży przyrost wydajności daje się uzyskać.

Jako systemy testowe posłużyły mi wirtualki uruchomione pod kontrolą VirtualBOX’a z zainstalowanym aktualnym Debianem Squeeze. Przydzieliłem im po 1 GB RAM’u i 2 rdzenie CPU. Wirtualki te raczej nie są highend’em ale do ogólnego porównania optymalizatorów będą w zupełności wystarczające.

Wyniki

Już na pierwszy rzut oka widać że opłaca się zainstalować dowolny optymalizator bo ich wydajność jest zbliżona a w stosunku do czystej instalacji pozwalają obsłużyć prawie czterokrotnie większy ruch. Przy czym system bez opcode cacher’a nie pokonał granicy 70 zapytań na sekundę - zaczął swapować i nie ukończył kolejnych testów.

Poniżej wykres przedstawiający ilość obsługiwanych żądań w zależności od ilości równoczesnych połączeń:

I jeszcze jeden wykres, na którym porównałem wydajność poszczególnych optymalizatorów względem czystego PHP’a

Wychodzi na to że przez większość testu eAccelerator był najszybszy, gdzieniegdzie przeplatając się z APC. XCache nieznacznie ale na całej długości poniżej dwóch wcześniejszych. Całościowe różnice pomiędzy optymalizatorami przeważnie nie przekraczały 3 zapytań/sekundę - więc różnice pomiędzy nimi są rzędu 1~2%. Można na tej podstawie wywnioskować że wydajność jest tak zbliżona iż nie powinna być jedynym kryterium wyboru optymalizatora dla naszego systemu.

Poniżej postaram się zebrać subiektywne oceny poszczególnych rozwiązań by dostarczyć dodatkowych argumentów.

eAccelerator

eAccelerator był najszybszy w teście ale miewałem z nim problemy (kilka razy ale…) stąd nie jest moim faworytem.

Zalety:

• zdecydowanie najszybszy,
• jest stosunkowo aktywnie rozwijany,
• dość stabilny,
• wbudowany encoder i dekoder skryptów (do dystrybucji kodu bez źródeł w postaci skompilowanej).

Wady:

• brak paczek w repozytoriach Debiana - ręczna kompilacja nie jest ciężka ale gdy trzeba go utrzymać na 30 serwerach to przestaje być zabawnie,
• pomimo że pojawiają się nowe wersje to ostatnio miałem problemy z pobraniem ich ze strony projektu - szukanie paczek “gdzieś” na sieci nie wydaje mi się bezpieczne,
• miałem problem z pewną dużą aplikacją, nie działała stabilnie pod eAcceleratorem,
• eAccelerator powstał na bazie kodu Turck MMCache (ten nie jest już rozwijany) -istnieją pewne wątpliwości licencyjne co do jego kodu…

PHP APC

APC pod względem wydajności nieznacznie ustępuje eAcceleratorowi. Ciekawą funkcją udostępnianą przez APC jest obsługa RFC1867 (File Upload Progress hook handler). Jest też pewna potwierdzona plotka mówiąca o włączeniu kodu APC do PHP’a 6. Teoretycznie jeżeli przesiądziemy się już teraz na APC to później powinno pójść łatwiej…

Zalety:

• dość szybki,
• aktywnie rozwijany,
• bardzo stabilny,
• dostępna paczka w repozytoriach Debiana (i z tego co wiem na wielu innych systemach też przeważnie wystarczają domyślne repozytoria)
• obsługa RFC1867 (upload progress),
• zostanie włączony do PHP od wersji 5.4,
• APC udostępnia API umożliwiające tworzenie własnych obiektów w pamięci cache współdzielonych pomiędzy zapytaniami np. by nie pobierać za każdym razem właściwości profilu z bazy, listy użytkowników, itp (coś w stylu memcached).
• dostępny jest ze skryptem apc.php, który pozwala zarządzać obiektami w cache, czyścić itp.

Wady:

• podobno bywa problematyczny w konfiguracji z fast-cgi (choć u mnie działa),
• przy mocno zapchanym cache’u czyszczenie go potrafiło się zwiesić.

XCache

Ostatni projekt rozwijany jest przez jednego z programistów lighttpd.  W chwili obecnej wydaje się być dość dojrzałym i wystarczająco stabilnym do produkcyjnego użycia. Choć gdy próbowałem z niego korzystać jakiś rok/dwa temu to miałem sporo losowych padów - niezależnych od obciążenia serwera.

Zalety:

• stabilny,
• aktywnie rozwijany z kilkoma gałęziami (stable/unstable/devel) - możemy wybrać czy potrzebujemy funkcji czy stabilności.

Wady:

• nieznacznie, ale jednak najniższa wydajność,
• miałem z nim mało styczności a szybko zraziłem się do kiepskiej stabilności - obecnie wydaje się że nie stanowi to problemu.

Podsumowanie i mój wybór

Do testu celowo wybrałem WordPress’a jako dość duży i wystarczająco skomplikowany projekt - jeśli on będzie działać stabilnie to większość mniejszych też powinna… Ku mojemu zaskoczeniu żaden z optymalizatorów nie sypnął błędami. Dziwiło mnie to bo jeszcze jakiś czas temu eAccelerator czasami losowo mi się sypał - działał przez tydzień i nagle zgon w sobotę po południu… Później próbowałem XCache i było podobnie… tylko gorzej bo problemy występowały częściej. APC testowałem jako ostatnie ale w wykorzystywanych przeze mnie aplikacjach zachowywał się bardzo stabilnie i przewidywalni. Jedyny problem z wieszaniem się podczas czyszczenia/usuwania elementu z cache’u można obejść stosunkowo szybkim restartem Apachego - skuteczne i efekt ten sam 😃 Na jednym z serwerów testuję APC w trybie fast-cgi od około dwóch miesięcy i jak na razie nie mogę narzekać (może w wolnej chwili uzupełnię to zestawienie o testy w trybie fast-cgi).

Obecnie w większości administrowanych przeze mnie serwerów z PHP’em standardowo instaluję APC. Wybór jest dla mnie tym bardziej oczywisty że paczka ta jest dostępna w standardowych repozytoriach (łatwość aktualizacji itd) - nie ma zatem potrzeby jak w przypadku eAcceleratora instalowania wielu paczek z zależnościami by móc skompilować 1 moduł.

Dodatkową zaletą jest fakt że APC ma być standardowo wbudowany w kolejne wersje PHP’a - jeżeli w rozwijanych aplikacjach już teraz zwróci się uwagę na integrację z tym rozwiązaniem to w przyszłości migracja nie powinna przysporzyć problemów.

Jeżeli się wahasz - wybierz APC. Jeżeli w Twoim środowisku okaże się niestabilne zawsze możesz spróbować dwóch pozostałych rozwiązań.

Przydatne linki (część potwierdza moje obserwacje, są też testy z drupalem):
http://php.net/manual/en/book.apc.php 
http://xcache.lighttpd.net/ 
http://eaccelerator.net/   (w chwili pisanie strona nie działała 😃)
http://www.ducea.com/2006/10/30/php-accelerators/ 
http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html 
http://2bits.com/articles/benchmarking-apc-vs-eaccelerator-using-drupal.html 
http://hostingfu.com/article/increasing-php-application-performance-xcache