"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: > Don't want to rain on the party here, but I don't like the /static and > mod_rewrite approach at all (sorry Pier),
Oh, absolutely, I don't like that either... But in my specific case (VNU, with somewhat 8000/9000 hits per minute (we peak up sometimes at 400 hits per second), we need to use tricks (yes, tricks/hacks) to make that happen, because passing through (even on localhost) binary data at that rate is sometimes overkilling... It's a hack, but when you deal with _big_ numbers, oh boy, hacks can save you so many sleepless nights... :-) > [...] > The best solution should be a proxy-ing rock-solid HTTP stack up front > with a light-speed binary-oriented cache and cocoon doing *all* the > resource generation (and avoiding to cache binary results itself). A some sort of mod_cocoon_cache... And tell you what? Apache 2.0 was born with THAT in mind... Look here: <http://httpd.apache.org/docs-2.0/mod/mod_cache.html> As you can see mod_cache already relies on a pluggable storage manager. Just need to write one tied up with the cocoon cache and TADAAAA! it all works nicely! > *THIS* is the nirvana of the web serving architectures, because it > follows the REST architectural practices, it's friendly with unlimited > proxy distribution (think of backbone proxying in between your request > and the hosting server) I believe that we talked about it extensively enough to share the same vision, right? :-) :-) > designing the URI space so that it routes around technological problems > is a potentially *very* dangerous approach and I don't like it. I know, but noone wrote some pieces of code (yet)... _RIGHT_NOW_ the only way allowing you to do stuff like that is... well... the hack! :-) > the transparent proxy/cache solution *is* the key and reduces > administration overheads (and worldwide load distribution problems) by > orders of magnitude. Oh, did you notice that also the mod_proxy approach is pluggable in Apache 2.0? You don't really need to write a new mod_jk to make that work, all one needs to do is write a new backend system if we want to get more performances out of the baby... > Please, don't get me wrong: Pier suggestions are great and I'm so glad I > convinced him to come back to work here on cocoonland, but we must not > sit on those sysadmin tricks (even if clever and powerful) we must > design a system that stands the pressure both from a technological *and* > a human point of view. > > So, the URI space should be designed with *NO* technological constraints > imposed by the architecture. > > Just stating this loud and clear. Absolutely... I know that the solution is far from perfect, but if your website works today, Stefano, it's because of the hack! :-) That doesn't imply that we should sit on our asses and use that forever... It works now because there's nothing better at the moment, nothing allowing us to do things in a less hacky way, or faster... Note the words I used describing rewrite: [...] if we want to be really nasty, and starting to serve (for example) all our GIF and JPG files straight via Apache, we would need to use mod_rewrite. I know, mod_rewrite is ugly [...] There will be a friggin' working solution one day, it's just not there yet... Pier (Note to self: Even remotely, Stefano is hinting my subconscious mind to get down to my knees and write C code, remember to flame him for that one day) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
