On Mon, 2002-08-19 at 09:00, Alex Rousskov wrote: > On 19 Aug 2002, Ian Holsman wrote: >
Good .. thats fantastic news Alex. The other thing to remember is that in >our< case (yours may vary) connection setup/teardown may account for ~10ms, while the actual thing being reversed proxied is a order of magnitude (or more) larger, and this stuff just gets lost in the noise. --Ian > > I was thinking of doing something like this for quite some time. the > > only issues I can see are keepalives. > > There should be no problem with this approach as far as I know. Many > proxies, including open-source Squid, maintain the client-side > connection pool virtually independent from the server-side pool. > > > * do they handle things like cookies per request or per > > connection? > > Cookies are end-to-end things that are not related to hop-by-hop > connection management. > > > * authentication > > Same here unless you are talking about some proprietary authentication > methods that require certain connection reuse patterns (but those are > usually not proxied anyway). > > > * handling of keepalive timeouts might be tricky > > Not in general, AFAIK. You just maintain two connection pools. The > timeout and other algorithms are pretty much the same for each side. > > > * ie.. do keepalives keep some state, I am never sure > > Not sure what you mean by state here. There is no HTTP state, but, > yes, since a connection may survive several HTTP transactions, there > is some internal state to be kept (e.g., destination address, idle > timer, etc.) > > > there are also some other minor problems if you want to load balance the > > backendservers, as that would break. > > Yes, but load balancing needs special options and algorithms anyway. > Most of them are not really closely related to idle connection > management. > > > $0.02, > > Alex. > > -- > | HTTP performance - Web Polygraph benchmark > www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite > | all of the above - PolyBox appliance -- Ian Holsman Performance Measurement & Analysis CNET Networks PH: 415-344-2608
