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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--