"Gianugo Rabellino" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
