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.



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:

Reply via email to