Yes, you are quite correct in that a very large site (Yahoo, Google, etc) will use a caching ISP (aka Akami). In fact, I imagine that it would be a completely separate domain name so there would be no cookies and everyone down the chain can easily cache the content as well. Doesn't work for all object content (great for images) since JS for example might loose its ability to set cookies.
I'm not really considering these things anyhow, since 99% of what I work with is access controlled or could be at a moments notice. It all needs to be logged as well, down to the things like images. So I'm really just looking at dynamic requests. It bears noting that usually a set of servers serving static content could use KeepAlive and the dynamic ones not, and a lot of this discussion is meaningless. But, if you are say, Google Maps, and doing "AJAX" type stuff (or chat, if only more browsers supported multipart responses from your XMLHttpRequest object) then the situation changes -- you need the Keep-Alive connections for all your dynamic connections too. And now I'm back at the beginning of the thread. I have my doubts about stripping Apache2 down to something 'lightweight'. I have my own thoughts on how that project was engineered. But there is nothing like a SmackDown to see where the cookies crumble. Thanks! -steve-- On 8/11/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > Well, I am not sure about your conclusion there. Generally you don't > want trivial requests going through the heavyweight Apache process, so > you can either try to make Apache less heavyweight and separate out the > dynamic stuff which is what you are suggesting, or you can separate out > the trivial requests. The large players do the latter by Akamizing all > their static content or the trivially dynamic stuff and only handle > heavy requests on their own servers. For smaller players the common > solution is to have a separate set of servers doing static requests. > thttpd, Tux, lighttpd, etc. which are easier to strip down than the > heavier (and more flexible) Apache server. > > -Rasmus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
