On 3/13/18 1:58 PM, Daniel Gryniewicz wrote:
rpcping was not thread safe.  I have fixes for it incoming.

With DanG's significant help, we now have better timing results.

There was an implicit assumption in the ancient code that it was
calling single threaded tirpc, while ntirpc is multi-threaded.

The documentation on clock_gettime() says that we cannot obtain
correct timer results between threads.  The starting and stopping
timer calls must be on the same thread.

I've returned the code to the original design that records only
client replies, not the connection create and destroy.  As
expected, the reports have improved by that margin.

Same result.  More calls ::= slower times.

rpcping tcp localhost threads=1 count=500 (port=2049 program=100003 version=3 
procedure=0): mean 51285.7754, total 51285.7754
rpcping tcp localhost threads=1 count=1000 (port=2049 program=100003 version=3 
procedure=0): mean 44849.7587, total 44849.7587
rpcping tcp localhost threads=1 count=2000 (port=2049 program=100003 version=3 
procedure=0): mean 32418.8600, total 32418.8600
rpcping tcp localhost threads=1 count=3000 (port=2049 program=100003 version=3 
procedure=0): mean 22578.4432, total 22578.4432
rpcping tcp localhost threads=1 count=5000 (port=2049 program=100003 version=3 
procedure=0): mean 18748.8576, total 18748.8576
rpcping tcp localhost threads=1 count=7000 (port=2049 program=100003 version=3 
procedure=0): mean 18532.9326, total 18532.9326
rpcping tcp localhost threads=1 count=10000 (port=2049 program=100003 version=3 
procedure=0): mean 17750.2026, total 17750.2026

As before, multiple call threads are not helping:

rpcping tcp localhost threads=2 count=750 (port=2049 program=100003 version=3 
procedure=0): mean 14615.7612, total 29231.5224
rpcping tcp localhost threads=3 count=750 (port=2049 program=100003 version=3 
procedure=0): mean 8456.7597, total 25370.2792
rpcping tcp localhost threads=5 count=750 (port=2049 program=100003 version=3 
procedure=0): mean 3851.8920, total 19259.4602

We've tried limiting the number of reply threads (was one worker per
reply up to 500 with recycling above that), but the overhead of creating
threads is swamped by something else.  No consistent difference.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to