Jeg har utviklet en nettside, basert på WordPress, hvor vi hadde et problem med at den brukte alt for lang tid på å levere sidene til brukere, selv med bare 10-15 samtidige brukere. Problemet lå på Apache, som fikk serverloaden opp i omkring 7-8. Oppslag av hostnames i Apache var skrudd av og loggfilene var satt til å roteres hver dag for å forhindre alt for store filer. Siden PHP kjøres gjennom mod_php var dette neste stedet å undersøke. WordPress med et utallig antall plugins resulterer i svært mange PHP-filer som må lastes for hver eneste gang en nettside hentes. Selv et lite Javascript kan kreve mye ressurser dersom dette scriptet har behov for selv bare én enkelt variabel fra databasen. En caching-løsning som cacher HTML-sidene basert på URL og cookies, ala WP-Cache, var ikke noen god løsning, fordi sidene som vises for innloggede brukere ikke bare bestemmes av URL og cookies, men også av variabler hentet fra en database. Memcache ble benyttet for å cache variabler fra databasen for å minke antallet spørringer mot denne, men det hjalp ikke i lengden.
Løsningen på ytelsesproblemet kom med eAccelerator, en cache-løsning for PHP som cacher de kompilerte PHP-filene, slik at PHP ikke behøver å lese og kompilere alle PHP-filene for hver sidelasting. Andre nettbaserte løsninger som for eksempel benytter Java EE (Enterprise Edition) har en server som hele tiden kjører selv om ingen brukere besøker siden. Fordelen med dette er at alle filer med tilhørende klasser og andre ressurser allerede er lastet inn i minnet på serveren, noe som sparer diskaktivitet og prosessorkraft når brukere besøker siden din.
I dette prosjektet ble versjon 0.9.5 av eAccelerator benyttet. Uten å kjøre nøyaktige benchmarktester så virket denne løsningen betraktelig raskere; sidene lastet raskere i nettleserene og serverloaden er blitt gjennomsnittlig lavere.
eAccelerator finnes ikke i pakkesystemene til Ubuntu eller FreeBSD, så denne må manuelt lastes ned og kompileres. Man trenger dev-pakkene for PHP for å kompilere eAccelerator, da man trenger verktøyet phpize. Dev-pakken på Ubuntu heter php5-dev, eller php4-dev dersom denne versjonen benyttes.
phpize
./configure --enable-eaccelerator \
--with-php-config=/usr/bin/php-config
make && make install
Deretter må den aktuelle php.ini-filen som Apache benytter seg av for mod_php oppdateres med følgende innstillinger. Bemerk at kun første linjen er påkrevd. Standard katalog for cache-filene er /tmp/eaccelerator, så denne må opprettes og det må gis skriverettigheter til brukeren som Apache kjører som. På distribusjoner hvor /tmp katalogen slettes ved booting av operativsystemet bør cache_dir settes til en annen katalog, for eksempel /var/cache/eaccelerator. Verdiene i eksempelet nedenfor er hentet fra eAccelerator – Installing from source.
extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
WordPress har et litt rufsete rykte, blant annet på grunn av at en WordPress-side ikke tåler trykket dersom en artikkel skrevet i en WordPress-blogg havner på forsiden av for eksempel Digg. Muligens kan en slik cache-løsning være redningen for WordPress, og forsåvidt andre PHP-applikasjoner.
Oppdatering 07.03.2007 08:38 CET
Et problem med eAccelerator er at instansvariabler deklarert med protected vil få eAccelerator til å krasje dersom en klasse som arver på denne forsøker å aksessere disse protected variablene. Løsningen på dette er å deklarere dem som public. Ikke spesielt god designmetodikk, men det fungerer…