[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fwd: Re: suggestions for per request xslt perform

Subject: Re: Fwd: Re: suggestions for per request xslt performance?
From: Andrew Mason <andrew@xxxxxxxxxxxxxxx>
Date: Fri, 27 Apr 2007 08:56:29 +0930
Re: Fwd: Re:  suggestions for per request xslt  perform
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.