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 Mon, 03 Feb 2003 17:47:13 GMT
"Gianugo Rabellino" <gianugo@apache.org> wrote:

> Pier Fumagalli wrote:
>> 
>> Well, remember that now in Apache 2.0 mod_proxy and mod_cache are separated,
>> so, if you achieve proxy "full support" using HTTP, you'll be able to simply
>> replace the HTTP proxying module with something (Better? Faster? Is it
>> really needed?), and keep all that caching magic working at the same time...
> 
> Yep. Apache mod_proxy (+ mod_cache) for the average, Squid for more
> advanced users and Akamai for the huge boxes. :-)

Hm... I don't like squid that much... It doesn't allow you to do a bunch of
nifty stuff that Apache lets you do... It is a little bit faster, but speed
comes at a great price:

For example, you can't direct people to a holding page when the servlet
container is down, and this is something that I definitely need in my
production environment, plus as the Java Virtual Machine, "squid" is a
single-process server, if the one process crashes, you'll have to wait for a
restart and basically unable to serve requests.

Apache, instead, being multi-process in core, gives a lot more flexibility,
if one of your processes dies, well, you got another N processes (possibly
multithreaded) running smoothly, and something is _ever_ bound to port 80
ready to answer to HTTP requests! :-)

>> The only case where I see something different from mod_proxy to be used
>> would be in the case when you really need a lot of thrughput, and so you can
>> use things like shared memory and unix sockets/pipes between Apache and
>> Cocoon to basically avoid the re-parsing of the HTTP protocol and be as
>> close to the client as possible (a some sort of mod_cocoon)...
>> 
>> But of course that approach would mean having the Java code to rely on
>> something native, with the rather-obvious problems of portability and
>> maintainance... Quite complicated indeed... It wouldn't be 100% pure java
>> anymore...
> 
> Just out of curiosity, what do you think of a NIO based, pure java,
> lightweight HTTP server? I'm talking about projects like SEDA and
> derivatives (http://sourceforge.net/projects/seda).

Performance is good, but you always have to see what you're going to loose.
As I said earlier, the main disadvantage of non-native solutions (or Squid,
for that matters), means that you are going to have ONE only process
listening to your port 80... That is not good.

At least, it doesn't work for me, where hardware is not an issue, but
resilience is: I can throw in another E4500 to spread the load if I have
performance problems, but I cannot loose a hit (connection refused is not
acceptable in my workplace - although it still happens).

Jetty too has a NIO adapter (I know that it is completely different from
what your mentioning, I know) Greg was talking about something similar, but
he mentioned that if you wanted to use NIO you'd better move away from the
servlet spec (and I agree wholeheartedly).

Apache 2.1 or 2.2 should also feature non-blocking IO, and that would be
native, therefore _MUCH_ faster, but so far, as I'm "stuck" on MacOS/X for
all my development, I'm still kinda far from the non-blocking IO world...
The 1.4.1 JDK for Darwin should come out soon (the pre-release versions are
fairly good), we'll see when it's out final! :-)

    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