[SERVER-19975] 30% performance regression on simple insert workload on primary Created: 15/Aug/15  Updated: 19/Sep/15  Resolved: 21/Aug/15

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.1.5, 3.1.6
Fix Version/s: 3.1.8

Type: Bug Priority: Major - P3
Reporter: Bruce Lucas (Inactive) Assignee: Scott Hernandez (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-18498 New replica set configurations have p... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Saw a 30% performance decline between 3.1.4 and 3.1.5 in a simple insert workload - 8 threads of the following:

    every = 10000
    for (var i=0; i<500000; ) {
        var bulk = db.c.initializeUnorderedBulkOp();
        for (var j=0; j<every; j++, i++)
            bulk.insert({x:0})
        bulk.execute()
    }

Execution time in seconds:

        1-node rs    standalone     1-node rs
        wiredtiger   wiredtiger      mmapv1
3.0.5     19            11             90
3.1.4     20            12             91
3.1.5     28            12            109

No performance regression on standalone node, and regression is the primary, so presumably related to oplog insertion. Similar performance regression for both WT and mmapv1.

Did a git bisect and identified f302737346da1bfb46f5c3b295bfb7896daa1508 as the first bad commit, and this change is indeed related to oplog processing.

Even though this is a bit old at this point, more recent builds show similar (or worse) performance, so presumably this is still relevant.



 Comments   
Comment by Scott Hernandez (Inactive) [ 21/Aug/15 ]

Other commits may have contributed to restoring throughput other than the ones included here.

Comment by Githook User [ 21/Aug/15 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-19975: use cached protocol version (atomic)
Branch: master
https://github.com/mongodb/mongo/commit/9ad561b8a31f3b8233ac5f905e2b2a089c5b1302

Comment by Scott Hernandez (Inactive) [ 19/Aug/15 ]

I believe this may be due to the additional checks on protocol version and have a patch to address this which will be included in SERVER-19950.

Comment by Bruce Lucas (Inactive) [ 17/Aug/15 ]

Added timing above for 3.0.5 to clarify that this is a significant performance regression relative to 3.0.

Generated at Thu Feb 08 03:52:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.