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

[Andrew Mason <andrew@xxxxxxxxxxxxxxx>]

On Wednesday April 25 2007 09:02:48 pm Abel Braaksma wrote:
> Andrew Mason wrote:
> > It's also not just PHP that operates on a  per request
> > basis. Most scripting
> > languages work with apache in this way. Thus they will have
> > a significant
> > portion of each request time taken to import the stylesheet.
> >
> > I don't particularly like PHP either, [...] and I've got 0
> > chance of getting
> > the system admin to run apache2.
>
> Are you really serious of staying with your job? ... ;)
Well..... :)
>
> I vaguely remember having used PHP with some memcache module that tries
> to keep objects available in memory. Is that something you could try?
> Possibly it only works with Apache 2.0 or 2.2 though...
Not  a bad idea. I know this works with databases and if it works for the XSLT 
processor that would be something i could probably get added to the server.
Hadn't even thought of trying it for the XSLT processor.

>
> >  I am sure
> > that we could convince the boss to pay someone to add this
> > functionality,
>
> Good to know. Have you considered the following, which is often chosen
> when something cannot (or can't easily) be done in the current language
> you are using: create a small project with an open interface, with a
> language that does your job best (Java, or anything) and use your own
> tools (PHP) to write to that interface.
This was something I had thought about doing. It would allow the system to 
scale nicely,  however it then adds additional latency (which is what I was 
trying to avoid in the first place). I haven't tested it to see if there is 
less or more latency doing this than importing the stylesheet   on a  / 
request basis.

Also , this requires another box. Which would be fine if we weren't  Co-lo, 
however the cost of the rack over time is probably more expensive than paying 
someone to add an export/load option to libxslt assuming it's even possible. 
So I guess that would be our preferred solution should anyone be interested.

>
> It really isn't that hard to make. If I understand you correctly you
> have a situation where you:
>   - can't control what system is used (openBSD)
>   - can't control what language is used (PHP)
>   - can't control what techniques or tools are used (libxslt)
>
> Perhaps you can convince your sysadmin to create one (separate) sandbox
> system, where you have all control (you use, say, Java + Saxon, which
> gives you the freedom of XSLT 2.0 and any Unix variant that your
> sysadmin digs *and* can run Java JVM).
unfortunately OpenBSD is the only UNIX variety he "digs"...not even FreeBSD 
which i understand runs java ok. :(

> Now, it should not take anything 
> more than a few days to build a SOAP server, and make PHP send a SOAP
> message to this server where the returned message contains the
> transformed XML.
>
> This way you will have a lot of freedom in controlling both performance
> and your techniques of choice (i.e., pragmatic programmers should
> *always* choose the best tool that fits a job, not the tool they
> understand best or is easiest available) because you completely separate
> this module from the rest of your sources.
It's pretty seperate anyway :)



many thanks
Andrew
>
> If you need such a system I am happy to help you with both the Java and
> PHP part (but contact me offlist then and we discuss the requirements).

>
> HTH,
>
> Cheers,
> -- Abel Braaksma