NanoPool Benchmark
Tuesday, 15. September 2009, 21:55:12
Had the opportunity to test NanoPool on an 8-core machine today. The primary purpose was to decide between two possible fixed for gh-issue #8 (a connection leak was possible with unlucky timing between a pool resize and shutting the pool down).
The test was a success overall, but a pattern emerged from the data that highlighted an undesirable behavior.
The three major humps in this chart shows three different sets of test runs, with a varying threads-to-connections factor (the X-axis number). As it turns out, the pool will show a negative throughput scaling when the number of threads accessing the pool concurrently exceeds the number of connections. The Y-axis number is the number of open/close cycles that can be squeezed through the pool in 650 milliseconds.
The reason is probably that the default ContentionHandler have a relatively high spin-rate for undersized pools. The high spin-rate will burn CPU resources that could otherwise be used by other threads to complete their work and let their connections return to the pool.
This effect is a property of NanoPools lock-less design, and I'm not sure if it is possible to deal with this behavior without compromising that principle. But one thing is certain: when you create a pool, make sure it's big enough (or use a resizing ContentionHandler).
If the pool had handled the contention ideally, the third hump would be roughly equal to, or only slightly less than, the second hump.
The test was a success overall, but a pattern emerged from the data that highlighted an undesirable behavior.
The three major humps in this chart shows three different sets of test runs, with a varying threads-to-connections factor (the X-axis number). As it turns out, the pool will show a negative throughput scaling when the number of threads accessing the pool concurrently exceeds the number of connections. The Y-axis number is the number of open/close cycles that can be squeezed through the pool in 650 milliseconds.
The reason is probably that the default ContentionHandler have a relatively high spin-rate for undersized pools. The high spin-rate will burn CPU resources that could otherwise be used by other threads to complete their work and let their connections return to the pool.
This effect is a property of NanoPools lock-less design, and I'm not sure if it is possible to deal with this behavior without compromising that principle. But one thing is certain: when you create a pool, make sure it's big enough (or use a resizing ContentionHandler).
If the pool had handled the contention ideally, the third hump would be roughly equal to, or only slightly less than, the second hump.
WIDGETIZE
Christian Vest Hansen # 15. September 2009, 22:02
Christian Vest Hansen # 16. September 2009, 06:09
Also, in the first hump, the pool is twice as big as the number of threads that are pounding on it. We see that it scales in a nice and nearly straight line all the way up to 8 threads, and after that we are limited by the core count of the CPU.