[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: Fwd: Re: [xsl] suggestions for per request xslt performance?


Subject: Re: Fwd: Re: [xsl] suggestions for per request xslt performance?
From: Andrew Mason <andrew@xxxxxxxxxxxxxxx>
Date: Fri, 27 Apr 2007 08:56:29 +0930

On Thursday April 26 2007 07:21:29 pm James A. Robinson wrote:
> > > > I really appreciate your comments, however I'm not really looking
> > > > for a which language is better discussion at this time.  I'm trying
> > > > to see what options are available (to us at the moment) in regards
> > > > to reducing the cost of importing the stylesheet. If there are
>
> If we were in the Java world people would be telling you to use the JAXP
> API and cache the Templates object, giving you a cached object from
> which you can derive Transformer objects to run individual stylesheet
> executions.
>
> If no such facility exists directly with the PHP libxslt libraries,
> you might look to see if there exists a facility to cache function calls
> or objects.  Poking around online I see the following article:
>
>   http://www.onlamp.com/pub/a/php/2001/10/11/pearcache.html
>
> which looks promising for such functionality, it looks like you may be
> able to do things like cache the XSLTProcessor object and then reload
> it each time you want to use it in a script execution.
>
> The Web Service idea floated earlier is also a great idea, it's one
> we've used to great success to allow Perl scripts to talk to a very
> efficent Java based XSLT engine.  A single modern AMD or Intel based
> Linux or Solaris x86 server running Tomcat (or Apache+Tomcat) to serve
> up an XSLT engine in Java is a fairly easy way to give programs who can
> 'talk HTTP' access to a pretty powerful XSLT engine.
Thanks Jim. 
I will look into the pear cache option. As far as I know, you can't serialize 
the xsltprocessor in PHP5. Well you can, it just doesn't un-serialize into a 
working xslt processor. Maybe pear does something different that I am not 
aware of  but i will try it and see.

The main issues with http solution is that it requires  another box. Customers 
who don't host directly with us ( around 50% currently ) will be at a 
significant disadvantage and I want to avoid any kind of lock in if possible.

There is also the Java on openBSD issue but i have been told there is a gnu 
classpath solution so that could be addressed in other ways.

kind regards
Andrew M
>
>
> Jim
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> James A. Robinson                       jim.robinson@xxxxxxxxxxxx
> Stanford University HighWire Press      http://highwire.stanford.edu/
> +1 650 7237294 (Work)                   +1 650 7259335 (Fax)


Current Thread
Keywords