Re: [xslt] libxslt processor dump/load

[Andrew Mason <andrew katalyst com au>]

Hi Daniel,
Thanks for the the prompt reply. 
On Friday May 4 2007 06:07:59 am Daniel Veillard wrote:
 It seems the main
> problem is that Apache was designed as an HTTP server i.e. an
> engine with little state, where having forked servers is not
> a problem, 
yes

> but when used with PHP this is not the case anymore. 
Thats not entirely true. You have state in the form of sessions but the DOM in 
php5 is completely un-serializable, probably because it's not needed, the 
loading of xml is extremely fast. 

PHP is done on a per/request basis. So each thread/ process has it's own php 
process attached to it. You can't share between two different 
processes/threads afaik, at least not with a standard PHP installation 
available on "other" hosts. This is good for hosting lots of unrelated (share 
nothing) small sites on the same host and i guess why most of the less 
expensive (i.e not java) hosting companies run php.


>
>   I understand the history but it seems we end up with a rather
> baroque architecture as a result, and I wonder if some of the
> problems raised by russian coders here a couple of years ago
> about using distinct memory pools in libxml2/libxslt wasn't also
> about trying to get rid of this problem.
 A collegue and  went through and profiled the libxslt running our large 
stylesheets and it seemed that it was doing alot of malloc calls, and it 
spent the majority of time doing memory related things.The larger the 
stylesheets the more time it spent doing that. Which i guess is a result of 
it parsing an unknown sized document.

The time actually spent processing the document was insignificant.


>
>   This looks like an interesting hack, certainly more efficient
> but the real solution would be to run fully threaded in a single
> process IMHO.
We might be able  to use PHP in fast-cgi configuration on our own server which 
might allow this to happen. The main thing is that not all of  our  clients 
host with us.

We don't want them to be "locked in" to using us, but we still want to give 
them a quality site, using the best tool for the job. Generating "content" in 
xml  and using xslt to transform that to a particular type of view is IMO is 
using the best tool for the job.

I really appreciate your help. I think we will probably have to go back and 
consider how / when we are doing the XSLT to  achieve better results. 

Even with small stylesheets (12k), it still creates a noticable req/s hit 
though.

I know it's not an issue with libxslt, more how PHP interacts with apache , 
but the currently the way this works is good in some (common) scenarios.
I wasn't at all trying to imply that there was anything wrong with how libxslt 
is  working. Apologies if you thought I was suggesting that. I was just 
trying to say that libxslt assumes that your using it a particular way which 
isn't always possible. I was just curious to see if there was a work around 
for that, but it seems not. I guess those customers that need a high req/sec 
can probably pay for a dedicated machine for  to be hosted on anyway.

Thank you for your time and thank you for a great library.
Andrew


>
> Daniel