[SERVER-22716] MongoDB authentication is 37x slower in 3.0.8 vs 2.6.11 Created: 18/Feb/16 Updated: 08/Jan/24 Resolved: 22/Mar/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance, Security |
| Affects Version/s: | 3.0.8 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Scott Kurowski | Assignee: | Andreas Nilsson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OS X, Linux |
||
| Issue Links: |
|
|||||||||
| Backwards Compatibility: | Fully Compatible | |||||||||
| Operating System: | ALL | |||||||||
| Steps To Reproduce: | Reproduced with non-enterprise versions 3.0.8 and 2.6.11 using Node.js driver driver 5.4.1 with module 2.1.3. Swapping only the MongoDB binaries used and clean data folder paths and using the same Node.js driver and test code in both timing runs. Prequisites: Install mtools, m and node on single Mac OS X system. Install both mongodb versions using m. Cluster configuration for 2.6.11: Cluster configuration for 3.0.8: When the cluster is spun-up, add userid before running the test Node.js code:
Run a node.js script that opens multiple connections to the node_test_db mongos process in a batch, then authenticates those connections in a batch, and reporting the total timings for each batch. |
|||||||||
| Sprint: | Security 10 (02/19/16), Security 11 (03/11/16), Security 12 (04/01/16) | |||||||||
| Participants: | ||||||||||
| Description |
|
Connections timings remain similar, however authentication is about 37x slower and test timings of various counts of authenticated connections show a linear timing correlation with connection count. Version 2.6.11 Repro Test Timings
Version 3.0.8 Repro Test Timings
Reproduced with non-enterprise versions 3.0.8 and 2.6.11 using Node.js driver 5.4.1 with module 2.1.3. |
| Comments |
| Comment by Andreas Nilsson [ 22/Mar/16 ] |
|
Per offline discussion we did some investigation into this, and this behavior is expected. SCRAM-SHA-1 requires authenticating clients perform a large amount of computation to produce a SaltedPassword. This is intended to make brute forcing the password from the authentication exchange computationally impractical. In the provided workload, all the CPU time spent was in the client application, as it computed this SaltedPassword. Using a more recent version of the Node.js driver with dynamic pool sizing will prevent the application from blocking on startup while waiting to preallocate its connection pools. Dynamic pool sizing is likely sufficient for most use cases. I will go ahead and close this ticket as "Community Answered". Kind regards, |