On 21/07/2012 7:53 a.m., James M Snell wrote:
>
>
> On Fri, Jul 20, 2012 at 12:46 PM, Willy Tarreau <w@1wt.eu
> <mailto:w@1wt.eu>> wrote:
>
> On Fri, Jul 20, 2012 at 02:35:00PM -0500, Zhong Yu wrote:
> > What are the reasons for such great efforts to keep connection alive
> > when a 100-continue fails? Is it really a big deal to drop
> connections
> > once in a while?
>
> Some webservice clients make extensive use of Expect: 100-continue
> over
> connection pools to avoid sending useless data and to keep the
> connections
> open. In fact, we're realizing that in the end it does not work
> (unless
> chunked encoding is used).
>
>
> +1 .. I've had similar experience. It's one of those things that
> sounds great in theory but in practice it just doesn't work
> effectively... at least not well enough to justify it's use.
>
> - James
Depends on what the application considers to be its use-case.
For those of you shavign off RTT, it breaks your ideal situation by
adding RTT.
For services where TCP TIME_WAIT from closure is some large multiple of
RTT, the single RTT added by Expect is saved many times over by total
throughput capacity on the re-usable connection. Particularly since
those types of connections are usually only seen between two piece of
high-performance middleware and not by the end-user or origin server. In
such middleware Connection:close is a major problem impacting many other
users, not just the one being very helpful by sending Expect.
> In the end, these WS clients might as well not send Expect and
> save one
> round trip and one packet in each direction since the only benefit of
> it goes away in case of failure, which is the only reason for using
> Expect.
>
+1. For these cases. It makes little sense to use Expect: without
chunked or some other nice way to early-abort the entity when the race
is lost.
Amos