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