Clay Gerrard 5f95e1bece Use bigger GreenPool for concurrent EC ...

We're getting some blockage trying to feed backup requests in waterfall
EC because the pool_size was limited to the initial batch of requests.
This was (un?)fortunately working out in practice because there were
lots of initial primary fragment requests and some would inevitably be
quick enough to make room for the pending feeder requests.  But when
enough of the initial requests were slow (network issue at the proxy?)
we wouldn't have the expected number of pending backup requests
in-flight.  Since concurrent EC should never make extra requests to
non-primaries (at least not until an existing primary request
completes) ec_n_unique_fragments makes a reasonable cap for the pool.

Drive-bys:

 * Don't make concurrent_ec_extra_requests unless you have enabled
   concurrent_gets.
 * Improved mock_http_connect extra requests tracking formatting
 * FakeStatus __repr__'s w/ status code in AssertionErrors

Change-Id: Iec579ed874ef097c659dc80fff1ba326b6da05e9

2020-09-25 09:47:40 -05:00

246 KiB

Raw Blame History

View Raw