[xsl] suggestions for per request xslt performance?

Subject: [xsl] suggestions for per request xslt performance?
From: Andrew Mason <andrew@xxxxxxxxxxxxxxx>
Date: Tue, 24 Apr 2007 15:57:55 +0930
Hello all,

The web development company I work for is using libxsl via PHP5.
We have a build environment which will create static html where possible, 
however we are currently using the same stylesheets to transform the xml 
dynamically where we have to. We have noticed that with large stylesheets 
(174k all up)  there is significant overhead in actually importing the 
stylesheet
i.e
$xsltprocessor->importStylesheet( $xsldom );
which i believe calls the function xsltParseStylesheet in xslt.c ,

At a light to moderate load this works well but it does degrade fairly quickly 
when additional load is placed on the server.

The building and manipulation of the  DomDocument, and the actual processing 
of the style sheets however are extremely fast.

I understand that this is not at all a bug, and the intention of the the  
xsltprocessor is to build it and process many times. Unfortunately, I don't 
know of a way to do this with scripting languages such as  php,perl etc... 
which are run on a per request basis.

Aside from reducing the  bulk of the XSLT, is there anything that can be done 
from an XSL stylesheet POV or from a libxslt POV to reduce the  overhead  of 
importing the stylesheet. 

How difficult would it be to export  the xslt processor  once it has been 
build and upon subsequent requests instruct libxslt to use that...?

Is this a problem that other people are encountering also ?


libxml / libxslt  solves alot of problems for us 


We have had a look at things like mod_xslt, axkit and  Suns' XSLTC. mod_xslt 
and axkit don't really solve the problem that we are having and our 
production servers are running OpenBSD so having Java isn't ideal. We also 
know that libxml and libxsl are fast and well tested, so we  risk hitting 
another bottle neck further down the road with other xslt processors.

Thanks in Advance
Andrew M

Current Thread