Graham Leggett wrote: > >> 2. The optimization only helps for the last chunk being read from the backend >> which has the size of ProxyIOBufferSize at most. If ProxyIOBuffer size >> isn't >> set explicitly this amounts to just 8k. I guess if you are having clients >> or connections that take a long time to consume just 8k you are troubled >> anyway. > > Which is why you would increase the size from 8k to something big enough > to hold your complete pages. The CNN home page for example is 92k.
Also consider today that a server on broadband can easily spew 1gb/sec bandwidth at the client. If this is composed content (or proxied, etc, but not sendfiled) it would make sense to allow multiple buffer pages and/or resizing buffer pages, in a <Location > or <Files > or <Proxy > specific context. Since mismatched buffer pages are a loser from the recycling pov, it seems sensible to set that based on traffic and bandwidth, but then take advantage of multiple pages to complete the handoff from the backend connection pool to the client facing connection pool.
