|
Some explanation is probably due since I hear these graphs might see wider consumption. The mongodes and mongoses involved had a 1s sleep introduced at the start of each client thread. This artificially simulates a predictably slow connection. The c driver program in bpcps-benchmark.zip starts 100 threads each with a single mongoc client connection. Each thread sends out a find with 1s javascript sleep in its $where.
This means that the initial connection+find to the mongos takes at least 3s and reconnecting to a mongod+find takes at least 2s. Without any new connections being made, an operation takes at least 1s--which is the steady state seen in steady-plot2.png. Each step you see in the graphs is one less connection needing to be made somewhere along the CRUD-associated path. Both axis of the charts are in ms. The X axis is the duration from when the test began to the start of a find operation from the client. The Y axis is the latency of that same operation. Blue is max, green is median, yellow is min. Honestly, I suspect that just dots would have painted the picture about as well.
The clear signal these graphs show is due to two conditions:
- The operations need to take long enough that more connections are needed. If operations are quick, then you won't need many active connections.
- The actual time to establish a connection needs to be substantial with respect to the time to perform the operation. If this isn't true, than variance around the operation can make it hard to see the cost of connections.
|