Subject: Re: Fwd: Re: 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)
|