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