With N=10 and num_calls=100, on Lemon, test_rbt averages 2.8M
reqs/s. That's about half the rate when N=1, which I think is
expected. If this is really an available rbt in-order
search-remove-insert retire rate when N is 10, my intuition would
be it's sufficiently fast not to be
1 What is the peak outstanding size of outstanding calls
1.1 if e.g. > 100k is that correct: as last week, why would a sensible
client issue more than e.g. 1000 calls without seeing replies?
1.3 if outstanding calls is <= 1, why can test_rbt retire millions of
duty cycles / s in that
On 3/24/18 7:50 AM, William Allen Simpson wrote:
Noting that the top problem is exactly my prediction by knowledge of
the code:
clnt_req_callback() opr_rbtree_insert()
The second is also exactly as expected:
svc_rqst_expire_insert() opr_rbtree_insert() svc_rqst_expire_cmpf()
These are
Using local file tests/rpcping.
Using local file ../profile.
Total: 989 samples
321 32.5% 32.5% 321 32.5% svc_rqst_expire_cmpf
149 15.1% 47.5% 475 48.0% opr_rbtree_insert
139 14.1% 61.6% 140 14.2% __writev
56 5.7% 67.2% 66 6.7%
