Scriptorama.nl

Het heeft even geduurd, net als met namespaces, maar uiteindelijk is ook de PHAR extensie in de core distributie van PHP 5.3 terecht gekomen. De PHAR extensie, welke standaard wordt meegecompileerd in de nieuwe PHP versie, stelt je in staat al je PHP code te bundelen tot 1 PHAR bestand en de website ook direct uit dit bestand te serveren.

Hoe werkt PHAR?

Wacht. Wat? Alle PHP bestanden bundelen tot 1 bestand? Hoe kan PHP daar in godsnaam mee omgaan? Nouja, dat is de magie van de PHAR extensie. Iets minder magisch gesproken; er zijn twee belangrijke elementen die bijdragen aan deze extensie. Ten eerste is daar de __HALT_COMPILER() instructie die sinds PHP 5.2 in PHP zit. Hiermee kun je als scripter aangeven dat de PHP parser vanaf dat punt klaar is en moet stoppen met parsen. Dit maakt het mogelijk om alles in 1 bestand te hebben.

Ten tweede is daar de phar:// stream wrapper. Deze implementeert de kennis van het bestandsformaat en maakt het mogelijk om andere bestanden uit het archief bestand te includen. Tenslotte haalt de PHAR extensie nog enkele trucjes uit om het gebruik van PHAR extensies nog iets makkelijker te maken.

Hoe maak ik een PHAR bestand?

Met __HALT_COMPILER() en de phar stream wrapper heb je verder niet zo heel veel te maken. Dat is de onderliggende techniek. Met de bijgeleverde Phar klasse hoef je enkel maar de juiste methodes aan te roepen om een PHAR bestand te maken.

PHAR biedt enkele manieren om een PHAR bestand samen te stellen. Je kunt bijvoorbeeld een hele directory opnemen in een PHAR bestand door PHAR::buildFromDirectory() te gebruiken:

Deze code maakt een nieuw PHAR bestand mijn-project.phar aan met daarin de inhoud van /pad/naar/mijn-project. Om de code ook daadwerkelijk op te starten hebben we een zogenaamde stub nodig, een soort opstart bestand. Met PHAR::createDefaultStub() heb je de meest functionele stub, maar, zoals we later zullen zien, is deze stub ook wat langzaam.

Een andere manier is om met een setje iterators en PHAR::buildFromIterator() precies op te geven welke bestanden en eventuele directories waar ze in staan op te nemen in het PHAR archief:

Naar mijn bescheiden mening is het het makkelijkst om PHAR bestanden op de commandline te genereren. Geen gedoe met permissies, memory limits of execution time. Uit veiligheidsoverwegingen staat PHAR je niet zonder meer toe om PHAR bestanden weg te schrijven. Daarvoor zul je de configuratie optie phar.readonly voor moeten wijzigen. Dat kunnen we doen met de '-d' commandline optie voor PHP:

Het resulterende .phar bestand plaats je in je webroot en de webapplicatie kan vervolgens benaderd worden door het PHAR bestand te bezoeken via je browser. Vergeet niet om .phar toe te voegen aan de extensies die door de PHP parser worden opgepakt:

Of, als dat geen optie is, kun je het PHAR bestand ook gewoon hernoemen naar .php.

Performance

Een niet onbelangrijk aspect aan PHAR is natuurlijk de performance. In een vroeger stadium was PHAR een stuk trager dan een gewoon script, maar tegenwoordig is PHAR in staat om vanuit een PHAR bestand vrijwel dezelfde prestaties te leveren als dan dat de bestanden gewoon vanaf het filesystem worden geserveerd. Daar moet je echter wel iets voor doen.

PHAR bestand cachen

Ten eerste is het mogelijk om je PHAR bestand te laten cachen op het moment dat de webserver start. Dit doe je met de configuratie optie phar.cache_list, welke je overigens alleen van httpd.conf of php.ini kunt configureren:

Dit is uiteraard niet nuttig voor development, want, zoals ik al zei, het PHAR bestand wordt gecached op het moment dat de server start en voor wijzigingen zul je de webserver dan moeten herstarten. Maar, deze optie is wel cruciaal om acceptabele performance te behalen.

Een eigen stub creeëren

Uit mijn eerste tests bleek dat PHAR eigenlijk altijd 1/3e trager was dan gewone bestanden. Maar dat zou niet moeten, want de auteurs van PHAR claimde een verwaarloosbaar verschil tussen een webapplicatie van uit een PHAR archief en een webapplicatie direct op het filesystem. Een mailtje naar een van de auteurs bracht duidelijkheid: probeer eens een eigen kortere stub dan die standaard wordt mee geleverd en dat hielp!

De standaard stub bevat PHP code om het PHAR bestand ook op PHP 5.2 installaties te kunnen draaien. Aangezien PHP 5.2 nog niet de PHAR extensie bevat, moet deze PHP code de nodige trucs uit halen om het PHAR bestand te kunnen uitvoeren. Dat blijkt, de stub is zo'n 7Kb aan PHP code.

Op het moment dat je deze standaard stub weglaat en alleen gebruikt wat je voor PHP 5.3 nodig hebt - komt - op een manier die mij nog niet helemaal duidelijk is, de performance vrijwel gelijk te liggen met dat van het serveren vanaf het filesystem:

Omgaan met externe directories en bestanden

Er zijn bepaalde bestanden die je niet in je PHAR bestand wil hebben. Denk bijvoorbeeld aan een configuratie bestand. Je wilt niet voor iedere config update je PHAR bestand updaten. Maar ook bestanden die de gebruiker kan uploaden moeten uiteraard niet in het PHAR bestand terecht komen. Tegelijkertijd wil je niet (teveel) PHAR specifieke code toevoegen aan je project. Om deze problemen op te lossen kun je in je stub een directory of een bestand mounten. Dit maakt in feite een brug naar bestanden buiten het PHAR archief.

Om een configuratie bestand toe te voegen van buiten het PHAR bestand voeg je bijvoorbeeld het volgende toe aan je stub code:

Oftewel:

Op het moment dat een PHP bestand in het PHAR archief het bestand config.intern.php probeert te benaderen, zal deze doorgesluisd worden naar het config.extern.php dat naast het PHAR archief staat.

Conclusie

Dit artikel is slechts een korte introductie tot PHAR en beschrijft niet alle mogelijkheden, zoals het feit dat de PHAR extensie ook ZIP en TAR bestanden kan gebruiken, of dat de PHAR API meer mogelijkheden biedt om PHAR bestanden te manipuleren dan hier beschreven. Het loont dus om de handleiding van PHAR nog eens goed door te nemen als je hier mee aan slag gaat.

Het nut van PHAR zal, denk ik dan, zich voornamelijk tonen bij verschillende kleinere webapplicaties die met het gebruik van PHAR enigzins gemakkelijker te beheren zijn. Daarbuiten weet ik niet zo zeker of PHAR echt een groot publiek zal aanspreken.

Een van redenen waarom is ik dat denk is dat om z'n volledige potentie te bereiken moet het ontwikkelaars beperken, het PHAR bestand wordt gecached door de webserver en er moet een server restart aan te pas komen om de cache te reloaden. Dat is nou net iets waar we als PHP ontwikkelaars gelukkig geen last van hadden. Daarbij zullen virtual hosters niet erg happig zijn om een dergelijke opzet en dat beperkt het eventuele gebruik aanzienlijk.

Wat denk jij? Zal het gemak dat het beheren van PHAR bestanden biedt het ongemak het hoofd bieden en van PHAR een populaire nieuwe extensie maken? Of, zie jij misschien voordelen aan PHAR die ik over het hoofd zie? Laat wat horen in de comments!