Bei Projekten mit intensiver Nutzung von XSL bzw. XSLT macht die Verwendung des XSL Bytecode Caches sehr viel Sinn, siehe dazu auch diese sehr umfassende Erklärung meines Kollegen Max.
Wichtig ist aber auch, wie sich der Cache hier verhält – und das ist bei der NY Times, welche die Extension “XSLCache” entwickelt hat, nachzulesen:
Neulich hatten wir die Aufgabe, in einem Projekt den XSL Cache zu “refreshen” – ohne jedoch die Webserver neu starten zu wollen. Es gibt da eine sehr simple und schnelle Lösung (Doku hier bei der NY Times):
The XSL cache uses the modification time (mtime) attribute of stylesheets to figure out if a file is newer than the cached version and needs to be updated. There are several cases where a file might change but the modification time remains old that you should avoid if you want the XSL cache to reload changed stylesheets correctly:
tar and rsync/scp can sometimes preserve the modification time of the archived/copied file. You must be careful about the following:
- tar, use the -m flag
- rsync, avoid using the -t/–times flag
- scp, avoid using the -p flag
- Be careful about radically adjusting the system clock and modifying XSL files. Similarly, clock skew between web servers and NFS shares may create issues.
- If all else fails, use touch to clear a stylesheet from the cache, by resetting its last modified timestamp.
In addition, this early release of XSL Cache does not use shared memory, so each PHP process/thread will have its own copy of the stylesheet. Although this is admittedly wasteful, the memory cost does not seem to be costly. However, if you use the cachesheet argument to clear a cached stylesheet from one web server process, it may still be cached in other processes.
(Quelle: http://code.nytimes.com/projects/xslcache/wiki/StaleCaches)
