Subject: Re: [xsl] suggestions for per request xslt performance? From: Andrew Mason <andrew@xxxxxxxxxxxxxxx> Date: Fri, 27 Apr 2007 09:38:29 +0930 |
On Thursday April 26 2007 08:21:42 pm Alexander Johannesen wrote: > On 4/24/07, Michael Kay <mike@xxxxxxxxxxxx> wrote: > > PHP appears to be one of those languages that gives you great development > > productivity until you want to do something a little bit more > > complicated, and then it leaves you stranded. > > No, I'd rather say it's one of those languages which a lot of people > think can't do a lot of things it really can do. I guess it comes from > it's simpler hacker-friendly background, and everyone loves to kick > the underdog. > > I use PHP 5.1 (or 5.2 for braver moments) professionally, and I have > yet to discover any problem I couldn't solve with it, enterprise or > otherwise. It's not about the language, but how you design software. > > Just like with Java you can run PHP in a servlet-ish kinda way, at a > different port, which will cache and keep the XSLT stylesheets and all > in memory, and you ask it to transform your XML on demand. PHP can be > run from the command-line for this very purpose, and people have > written all sorts of things with it, including HTTPD, servlets and so > forth. However, this is not the modus operandi, so documentation is > scarce, but you certainly can do it. (And look to running PHP with > FastCGI for performance issues as well; you can keep a pool of > pre-loaded iterations) The other thing we could do is write a PHP daemon / xslt that uses a UNIX socket do a similar thing , however this still means that we have to run this for each web site or have at least the xslt processor for each website in memory. This works great when you are developing a handful of sites or for busy sites. We are currently hosting around 300 sites and be honest, 90% of the sites we host are going to be idle most of the time. They will get a high influx of traffic every now and then but most of the time they are idle. So having an all those un-needed xslt processors in memory, doing not much is not ideal. We don't always know when the traffic is coming so we can't start and stop the daemon manually. If we had a handful of busy sites, it would be terrific, but we don't. The fast-cgi idea might be useful as we could probably add/remove from the pool dynamically as traffic increases or decreases. The issue is that the latency associated with each request is significant, and profiling shows that the everything up until the 'building' of the xslt processor is very efficient and also the actual processing of the stylesheet is very fast. I don't think it's a PHP userland thing. I am more than certain it would need to be done at a libxslt level.I've posted to the mailing list to see if it is of interest to anyone there. > > I'm also a bit wary of your 170k+ stylesheet. Are you sure this > stylesheet needs to be that large? (I can't fanthom that much XSLT > code ... Is this DocBook or something even more complicated?) The large bulk is w3c xforms are being translated into xhtml or html (depending on which is requested by the browser. Even still, if you are currently doing / request xslt with PHP5, install Xdebug and have a look at the output with kcachegrind or something like that. You will see that most of the time is spent importing the stylesheet. regards Andrew > > > Regards, > > Alexander
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] suggestions for per reque, Alexander Johannesen | Thread | RE: [xsl] suggestions for per reque, Andrew Mason |
Re: Fwd: Re: [xsl] suggestions for , Andrew Mason | Date | Re: [xsl] Converting from Framemake, Deborah Pickett |
Month |