Blog Posts

php xslcache extension by the New York Times

Via Gregor's del.icio.us feed, I found the xslcache extension for PHP published by the geeks at The New York Times, based on the original xslt extension. It caches the parsed XSLT stylesheets into your apache child memory (shared memory is on the todo list) and reuses it at the next request. This is something I wanted to do since a long time, but never did find the time for it. As - depending on the size of your stylesheets - the importing of XSLT stylesheets may take a considerable amount of time, this extension may really improve your website's performance. Many thanks to the NYT for publishing this. If I find the time some day, I will look more closely into it and check, if this could be integrated somehow into the mainstream xslt extension. Or if anyone else feels like it: Patches are welcome :)

There's also another interesting looking PHP extension worth checking out there: DBSLayer.

Related Entries:
- Added xslt profiling to PHP 5.3 and 6 CVS
- Pimp up your XSLT transformation
- Profile XSLT transformations within PHP
- Added DOMNode::getNodePath
- Calling PHP function from XSLT vs. native XSLT functions benchmark

About the author

Comments [1]

Rob Richards, 15.10.2007 21:13 CET

I too had wanted to do this and had actually started looking into it a few months ago when I also had found their code. My conclusion was that at least for now, their solution was probably the best way to go. All other implementations I could come up with have some major issues that need to be addressed.

I originally started trying to cache with APC, but (with some hints and tips from Rasmus - he had looked at doing this before starting with dom) found there was some difficulty in this, especially surrounding the speed of creating a new doc compared to copying.

I then took a look at integrating the fastxsl code into the XSL extension. This, however, presents another set of problems. The libxml2 memory handling routines need to be altered, thus they are altered on a global level.

Suppose we ignore the threading issues, and stick strictly with the process level. Changing the handlers on one process wont affect another process, so we just need to make sure that the handlers are only set and re-set when absolutely necessary. Again, let's ignore the fact that doing something like this is discouraged upon, every bit of libxml/libxslt functionality being used in the extension would then need to be audited to insure this memory mixing/flip flopping/scrambling wouldn't cause other problems. And after all that, future changes in libxml2/libxslt need to be accounted for.

So, while it might be possible to add the shared memory functionality might actually be made to work within a strictly controlled environment, the solution from the NYT guys would be the safest method imo to support at least some basic caching mechanism.

Add a comment

Your email adress will never be published. Comment spam will be deleted!