[PHP/XSLT] Sablotron erg langzaam?

[Terranca]

Ik ben weer bezig met een nieuw project, ben deze volledig (zover dat kan in PHP) OO aan het maken, en templates wil ik gaan verzorgen met een XSLT transformatie. Maar nu ik een klein deel van het projectje af heb, heb ik eens naar de performance gekeken dmv 'ab' (ApacheBenchmark).

Ik heb eerst de Sablotron/XSLT aangezet en gekeken hoe lang het duurde dat hij 50 keer 3 concurrent requests had verwerkt op een bepaald script. Dit duurde 10.455 seconden.

Vervolgens heb ik hetzelfde geprobeerd met alleen XML output (het enige wat in het script dus anders is, is dat er geen server-side XSL + XML -> XHTML is). Het resultaat hiervan was 4.229 seconden!

Ik was in de veronderstelling dat de XSL transformatie erg snel ging, maar als ik het script 50% sneller kan laten draaien door client-side XSL wordt dat opeens ook weer een optie.

Wat mijn vraag was: Is dit normaal of zit er waarschijnlijk een fout in mijn configuratie en/of XSL script (welke nog niet bijzonder groot is). Ook linkjes naar evt snellere alternatieven voor de transformatie zouden welkom zijn

[hobbit_be]

tja xslt is toch zowieso erug traag?

mijn ervaring met Cocoon (java server side framework volledig gebaseert op XSLT (meerdere passes zelfs)) is dat het gewoon niet echt snel te krijgen is ALS je voor elke request alles gaat doen. Gelukkig zitten er hopen caching etc bij maar toch gaat het nooit zo snel gaan als een 'normale' or low level approach. Er in Cocoon wordt het dan nog eerst compileerd naar een reusable servlet dus daar moet geen engine ofzo worden gestart.

Maar je moet kijken naar cost/benefit. Met cocoon was het heel gemakkelijk om een 80page puur dynamisch driven site met RDB en XMLDB support te bouwen, incluis businesslogic volledig in xml, alsook volledige data validation, etc.

zelf gebruik ik XSLT vaak om 'semi static' pages te maken (ie waar de content static is, maar online veranderd kan worden (als in een admin phase)). Dan maakt het helemaal niet uit hoe snel. mijn ervaring met PHP + XML is erug terughoudend na 3 keer weer een nieuwe API en bugs proberen te ontduiken. (om maar te zwijgen van Unicode support)..

[Genoil]

ja het beste is idd een soort van caching systeem in te bouwen. je transformeert alleen maar xml als er iets in de gegevens is veranderd, en slaat dat op als statische pagina. dit wordt natuurlijk wat lastiger als je pagina's hebt die voortdurend van inhoud veranderen, zoals een forum-thread, maar dan kan het nog steeds.

Het schijnt overigens dat de XSLT-engine in PHP5 een stukje sneller is dan Sablotron

[Verwijderd]

'k Heb ook al aan enkele sites gewerkt die we met Sablotron/PHP opgezet hebben.
Doordat Sablotron niet erg snel is en best veel CPU belasting levert hebben we gekeken naar manieren om e.e.a. te versnellen.
De beste manier bleek partiële caching te zijn:
Haal alle data van een blokje op en maak op grond van die data een key voor de cache. Als de data niet tot een cachehit leidt, dan moet je Sablotron wel aanspreken.
Neem je ook een versie van de XSL in de key mee, dan heb je jezelf ook ingedekt tegen xsl wijzigingen. Vlak na een xsl wijziging is de hele cache dan wel waardeloos, zodat je tijdelijk een piek in de CPU belasting ziet.
Door de XML en de XSL zo simpel mogelijk te houden (sorteren, bewerken, etc. zoveel mogelijk vermijden) is het geheel ook wat sneller te houden.
Door delen te cachen hoef je niet een hele pagina te laten renderen als alleen een deel gewijzigd is door veranderende data.

[Terranca]

Het idee van caching blijkt inderdaad erg goed te werken, heb er alleen nog een aantal problemen mee:

1. Ben er nog niet uit hoe je per 'blokje' kan cachen, dus bijvoorbeeld bepaalde nodes niet meenemen in de caching/vergelijking
2. Hoe krijg je het voor elkaar om XSL files die zelf ook nog andere XSL files importen of includen goed mee te laten doen voor de vergelijking. Dat wil zeggen: hoe kan je controleren of 1 van die geimporteerde XSL bestanden gewijzigd is.

Verder werkt de oplossing wel lekker rap! Dus bedankt voor de tips

[Verwijderd]

Terranca schreef op 22 december 2003 @ 21:19:

1. Ben er nog niet uit hoe je per 'blokje' kan cachen, dus bijvoorbeeld bepaalde nodes niet meenemen in de caching/vergelijking
2. Hoe krijg je het voor elkaar om XSL files die zelf ook nog andere XSL files importen of includen goed mee te laten doen voor de vergelijking. Dat wil zeggen: hoe kan je controleren of 1 van die geimporteerde XSL bestanden gewijzigd is.

ad 1) Je moet 'blokje' meer functioneel zien. Bijvoorbeeld: paginakop, menu, nieuws, itemlist, footer, etc. Een pagina is vaak opgebouwd uit enkele van dit soort blokken, die lang niet allemaal even vaak veranderen. Het menu wordt eens per maand gewijzigd, maar het nieuws meerdere keren per dag.
Door nu elk blok apart te cachen en te renderen hoef je minder vaak te renderen.
Ook kun je soms beter na het renderen stukjes data invoegen (bijvoorbeeld door markering aan te brengen en die later in te vullen); bijvoorbeeld als je in een vrij statisch blok het aantal bezoekers dat nu online is vermeldt.

ad 2) Hoe vaak wijzigt je XSL? is het de moeite waard om dat mee te nemen? Houd de XSL simpel en eenvoudig. Gebruik desnoods een (1) xsl bestand per 'blokje'.
Doe een filestat op het bestand om de datum/tijd van wijziging mee te nemen in de cache-key (filestats worden door PHP ook gecached! ;-) ).

Kortom: hou alles simpel en klein.