On Thursday April 26 2007 08:21:42 pm Alexander Johannesen wrote:
On 4/24/07, Michael Kay <mike(_at_)saxonica(_dot_)com> 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--