On Wednesday April 25 2007 09:02:48 pm Abel Braaksma wrote:
Andrew Mason wrote:
It's also not just PHP that operates on a per request
basis. Most scripting
languages work with apache in this way. Thus they will have
a significant
portion of each request time taken to import the stylesheet.
I don't particularly like PHP either, [...] and I've got 0
chance of getting
the system admin to run apache2.
Are you really serious of staying with your job? ... ;)
Well..... :)
I vaguely remember having used PHP with some memcache module that tries
to keep objects available in memory. Is that something you could try?
Possibly it only works with Apache 2.0 or 2.2 though...
Not a bad idea. I know this works with databases and if it works for the XSLT
processor that would be something i could probably get added to the server.
Hadn't even thought of trying it for the XSLT processor.
I am sure
that we could convince the boss to pay someone to add this
functionality,
Good to know. Have you considered the following, which is often chosen
when something cannot (or can't easily) be done in the current language
you are using: create a small project with an open interface, with a
language that does your job best (Java, or anything) and use your own
tools (PHP) to write to that interface.
This was something I had thought about doing. It would allow the system to
scale nicely, however it then adds additional latency (which is what I was
trying to avoid in the first place). I haven't tested it to see if there is
less or more latency doing this than importing the stylesheet on a /
request basis.
Also , this requires another box. Which would be fine if we weren't Co-lo,
however the cost of the rack over time is probably more expensive than paying
someone to add an export/load option to libxslt assuming it's even possible.
So I guess that would be our preferred solution should anyone be interested.
It really isn't that hard to make. If I understand you correctly you
have a situation where you:
- can't control what system is used (openBSD)
- can't control what language is used (PHP)
- can't control what techniques or tools are used (libxslt)
Perhaps you can convince your sysadmin to create one (separate) sandbox
system, where you have all control (you use, say, Java + Saxon, which
gives you the freedom of XSLT 2.0 and any Unix variant that your
sysadmin digs *and* can run Java JVM).
unfortunately OpenBSD is the only UNIX variety he "digs"...not even FreeBSD
which i understand runs java ok. :(
Now, it should not take anything
more than a few days to build a SOAP server, and make PHP send a SOAP
message to this server where the returned message contains the
transformed XML.
This way you will have a lot of freedom in controlling both performance
and your techniques of choice (i.e., pragmatic programmers should
*always* choose the best tool that fits a job, not the tool they
understand best or is easiest available) because you completely separate
this module from the rest of your sources.
It's pretty seperate anyway :)
many thanks
Andrew
If you need such a system I am happy to help you with both the Java and
PHP part (but contact me offlist then and we discuss the requirements).
HTH,
Cheers,
-- Abel Braaksma
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--