remove ResponseCache in favour of MDMFSlotReadProxy's cache

[davidsarah]

MDMFSlotReadProxy can already be initialised with share data which it uses in preference to fetching from the server. By exploiting this behaviour we can remove ResponseCache which does essentially the same thing.

ResponseCache had no functional tests of how it is used (as noted in 1045#comment:39, deactivating the cache by commenting out the line that adds entries to it will currently cause all tests to pass). The MDMFSlotReadProxy cache will require a test of this type.

One way to test that the cache is working would be to download a file, then break all of the servers holding its shares, then download it again in order to check that the shares are retrieved from cache rather than from the servers.

[davidsarah]

Ran out of time for 1.8.2.

[amiller]

I wrote a test that shows the cache is accessed during downloads from a NoNetworkGrid. ​https://github.com/amiller/tahoe-lafs/pull/5/files

I initially tried a "break-the-servers" test as per the ticket description, but this fails when the client finds no available versions. This seems consistent with the goals expressed in #465, which mentions performance but not availability.

[amiller]

After some time with Zooko tracing the use of the ResponseCache, we have a new strategy that involves removing it altogether. Instead we can make better use of the "_data" cache that already exists in !MDMFSlotReadyPoxy.

To begin with, here is a test that will run against trunk to count the remoteCalls to 'slot_readv,' i.e., the cache misses.

​https://github.com/amiller/tahoe-lafs/commit/21008a4d3eb3c491fbc48d9fb0e8e3eadd3c45a4

(It's probably not good form for this test to just printf counters to console, so I'll fix it as soon as someone suggests better alternatives)

[amiller]

This commit removes ResponseCache. Instead, the !MDMFSlotReadProxys created by ServerMap are kept around as instance variables. Retrieve is able to access these rather than creating its own instance. As a result, the MDMFSlotReadProxy._data cache obviates the need for the additional logic of ResponseCache.

Notably, by removing some logic that produces false cache misses, (​https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/mutable/retrieve.py?rev=a56e639346a4bb38#L293) the number of cache misses reduces from 84 to 60 in test_deepcheck_mdmf.

​https://github.com/amiller/tahoe-lafs/commit/cbdfb002a4bd8d16ec3b3faa608cfeb9e6325bfd

[amiller]

My test branch (amiller-1240-tests) differs from trunk only minimally, in particular the only test it removes was for ResponseCache itself. The feature branch (amiller-1240) also passes these tests now.

The only difference is that the number of slot_readv calls in trunk is 84 but goes down to 60 after replacing ResponseCache with this simpler alternative (according printouts in test_dirnode.Dirnode.test_deepcheck_cachemisses).

​Test branch ​Feature branch