This is probably the core issue for bug #402114, however I've co-opted that one to be a meta issue about various problems with 2a fetch over dumb transport performance.
The fetch code for 2a is specifically written to read one group at a time, keeping a buffer of recently read groups. The design was that we would have already built up groups that would be a reasonable size for fetching, so we wouldn't need to spend a lot of time sorting things out at future fetch times.
However, because of bugs like: bug #402645 (fetch might fragment) and bug #402652 (we don't opportunistically combine groups) we can easily end up with a case where we have many small groups.
(Also because of how we split up chk streams, which will soon be another bug post.)
We should instead do something logical, like try to fill up our local LRU Cache with each request (50MB uncompressed size), or at least something like make a min request of 64kB, etc.
Note that because each request *also* verifies the pack header, the overhead is even greater than a simple round trip. (though it is 40 bytes, it is also a seek to the beginning of the file, etc.)
Even if we are optimally packed, reading each group one at a time will cause a huge amount of latency.