cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [OT rant] there must be some way out of here...
Date Wed, 05 Feb 2003 00:09:51 GMT
On 4/2/03 23:06, "Miles Elam" <miles@pcextremist.com> wrote:
> 
> Honestly, if Cocoon is already demonstrating that PHP
> and Perl (directly generating HTML) are suboptimal methods for creating
> sites on a large scale, why use HTTPd at all?  mod_gzip?  Is it really
> so much more efficient than a compression servlet filter?  Is it really
> more efficient that a filter could be?  mod_speling?  Doesn't that start
> to fail when the files aren't static?  How would you map this to the
> sitemap?

Burn the heretic! Burn the heretic! Burn the heretic! :-) :-) :-)

Kidding, of course... No, all that you wrote is indeed not a great
advantage. Actually, I never used mod_gzip (which is, yes, faster than a
servlet filter just by matter of buffering stuff at a native level rather
than in a VM - we're talking about probably a 4/5% max, though) or
mod_speWHAT? :-)

At VNU we use Apache as a "switchboard" basically, our front-end to our
customers: we know it's reliable, we know it's always there, we know it that
when its configured correctly it allows us to play some tricks that we could
forget when using Tomcat (or whatever servlet container) alone... It's
"flexible"...

It's like our receptionist, our front-end to our customers: she's reliable,
she's always there, and if you tell her things in the right way, she can
even plan your next meeting when you're out of the office sick (or she can
play the trick of telling you're sick when you simply don't want to talk to
that person)...

Seriously, after 6 years of daily use, I wouldn't be able to get the same
results I get out of Apache out of any other HTTP stack available on this
planet, simply because they're not _there_ yet! :-)

> Okay, compiling that beast, I'll have to agree.  But aside from
> connecting Tomcat to HTTPd, I haven't really found it to be an issue --
> especially with the work done to make a web-based management console.

Oh, yes, forgot to say that Stefano was trying to install Tomcat on one of
my machines, an he knows that if he installs an "admin tool" he's going to
see his root privileges removed on the spot...

Yes, indeed, admin tools could be all-right, but my philosophy is don't rely
on them, otherwise when you're in troubles, you don't really have a clue on
where to put your hands. _Know_ what you're doing first, then make it easier
if it's a repetitive and stupid task, and remember that one day it will
happen that all you got left on your server is only a VT-100 serial
connection at 9600 BPS...

Connecting a servlet container with an HTTP server is something you should
know in every possible little minimal detail, because (at least this is true
in my case) your web-serving life relies on it.

> On another note: does anyone see a future in using something like gcj to
> more closely link a servlet engine to Apache HTTPd to regain the
> stability areas I mentioned earlier and to avoid the socket
> communications?  The only thing that pops out in my head is Batik as gcj
> doesn't have the graphics APIs down yet.

I believe, and I enjoyed the fact, that the Cocoon team is moving into one
clear direction: having the _best_ XML-based serving platform available on
the planet.

I _love_ the choice of having an interpreted sitemap, for example, or the
Javascript-based flow/continuations. The use of Avalon blocks is another...

Cocoon is not only the best (IMO) but as well the more _elegant_ solution
from a design point of view (it might not be _there_ yet, but I see all of
the folks who made this project great in the past few years going towards
the same goal).

Performances? All right, that's where the whole elegance comes into play.
Cocoon relies on Components, and in a beautiful separation-of-concerns
manner, it relies on individual components to be the most performant
components possible... Cocoon is the glue that ties together all those...

And if you ask me about the specific performance of the HTTP stack, don't
worry, there will be a day in which someone will come up with a solution to
tie one of the most optimized HTTP stack on this planet (Apache 2) and our
Cocoon glue in the fastest (and simplest) way possible...

It _will_ happen, I'm just waiting for Stefano to move to London so that he
can beat the crap out of me and make me work :-) :-)

My goal (and what I'm paid for) is to use Cocoon on a site that generates
roughly 0.5 millions hits per hour, and, yes, the baby can do it, easy! :-)

    Pier


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message