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 _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
