added a comment - - edited
Questions from Tim:
One thing to document explicitly, although I assume it is the only
logical way for this to be implemented: a replica read for an item
that is not resident in the caching layer will cause it to be fetched
from disk and its value cached. So the resident % for replica vbuckets
can have a significant impact on replica read performance.
Question for Jin:
is there a stat to track cache miss ratio for
Answer from Jin: ep_bg_fetch is the closest thing, which tells you the total number of background fetches. The one thing you can check is the change pre-replica-reads compared to replica-read scenario for the same data set.
No distinction in underlying ep engine whether it is fetching active or replica.
bg_fetch for replica reads vs. active reads, or are
those combined in a single stat?
Answer: see above. a single stat for both active and replica reads.
Any other stats that are exposed to
understand performance of replica reads?
I think the most important information for developers depends on the
client SDK, which I guess Matt will have to answer. For example, if
the bucket is configured with more than one replica copy, which
replica server will be queried?
Answer: All true
If the first attempt at a replica read
fails, will it try a 2nd (and 3rd) before returning an error? How can
that behavior be configured?
Answer: All depends on client.....