cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Issac Goldstand" <>
Subject Re: Cocoon in native C?
Date Thu, 10 May 2001 21:52:28 GMT
Wow.  That got a lot of feedback (although it's a good thing I checked the archives, because
I didn't actually see any of it - probably because I didn't confirm the subscribe fast enough).
But let me try to elaborate aon a few things:

Firstly, I understand and appreciate the JAXP and JAXB frameworks that allow for easy updating
of the respective runtime libraries (Cocoon, Xalan, etc).  However, let us take into consideration
that we have a finely-tuned Apache cluster which is already burdened with significant overhead
- mod_ssl, PHP, mod_perl and a couple of other little guys.  Now I already have both front
and back end servers running to get me the dynamic output. But if I want to put the raw output
into XML (which would give me a _huge_ plus), then I obviously must translate it - which for
now, really has to be done on the server side.  So this means, that I have to start up a JVMM
(or more?), additional external processes (read Tomcat), and compile a native C module into
Apache which lets me talk to Tomcat. On a fine tuned webserver cluster, that means significant
overhead and complications that I'd rather not deal with.  Now I appreciated the convenience
of JAXP being its own entity and therefore making Cocoon update easily (even dynamically?)
 But something akin to this _could_ be done by creating a libxslt library...  DLLs and .so's
allow for something very similar (OK - so not as good - but you can't have your cake and eat
it too, I guess).  In any case, even assuming that bytecode and CPU code run at _exactly_
the same speed (which is really impossible - close as bytecode might com), you'd still have
a performance loss - Apache must redirect the content to Tomcat, which in turn puts it through
Cocoon, returns it to Apache and spits it out to the client.  It's impossible that having
Apache do this on its own would not have a performance boost.  Plus, in a situation where
every single byte of memory counts, it means that instead of having to sacrifice a whole bunch
of webservers (read Apache processes) to let Tomcat run with, I can serve that many more requests
(and faster) by having the XSLT run inside the Apache process...

Now, I'm not saying that such a thing should replace Cocoon - that would be stupid for webmasters
who use JAVA servlets on their webservers.  I just don't think that in such a potentially
memory-touchy situation like a high-volume webserver, that such a thing is valid.  Now, maybe
if Tomcat was a bit like mod_perl, in that the JVM was loaded directly into the httpd process-space,
then I could see Cocoon staying as is - after all, if it's running in the same process, that
gives a big boost, and then the bytecode/CPU code speed difference alone would not justify
such a thing.  But as long as Tomcat (and more importantyly, the JVM itself) runs outside
the Apache process, I think there's justifyable reason for working on such a thing...  I'd
voulenteer myself, but I have far too little experience in XML to take on such an advanced,
important and critical project.

Just my two $0.02


Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.

Moving the mouse won't get you into trouble...  Clicking it might.

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

View raw message