[tahoe-dev] connection timeouts on VG2

[Brian Warner]

On 3/27/12 3:41 PM, David-Sarah Hopwood wrote:

>> Yeah, I have to admit it's kind of weird. It's because I designed
>> that code to minimize all forms of overhead:
>>
>>  * don't send any extra network traffic unless it's really necessary
>>  * don't replace/reset the timer very frequently
> 
> Is there reason to believe that timer resetting is an expensive
> operation? It doesn't seem as though it should be.

Probably not.. I must have had a bad experience too long ago to remember
that's coloring my expectations (maybe I was bitten by an O(n^2) sort
algorithm as a child or something). Actually, it was probably when I
implemented a reactor in C and had problems with the timer management.

But yeah, reset() is probably cleaner.

> HTTP 1.1 persistent connections are an important latency optimization
> and I think we should support them when we move to Tahoe-over-HTTP.
> That's somewhat independent of whether we use HTTP keepalives to
> attempt to keep idle connections open for longer than 115 seconds [*].

I think 115 seconds is a great value to pull all the sub-resources for a
single page through a single TCP connection. It might even let you share
that TCP connection for a few subsequent hits to the same site (if you
don't linger too long before following a link).

For Tahoe, in addition to multiple-requests-per-file (either upload or
download), it's also very common to touch multiple files in a row, when
we transfer a whole directory of stuff, or do a deep-check, etc. Or when
a human browses one directory, navigates to a subdirectory, and finally
views one or more files (this gives access patterns that are very
similar to the web browser case).

So I'm hoping that we can keep connections open for longer than 115
seconds. It's not fatal if we can't, but I have a hunch that we'll see
some disappointing slowdowns if we wind up with something as
connection-happy as a typical web browser.

cheers,
 -Brian