[SERVER-12787] Strange performance characteristics of write ops in shell Created: 19/Feb/14  Updated: 10/Dec/14  Resolved: 04/Mar/14

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Davide Italiano
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2014-03-02 19.24.33.png     PNG File Screenshot 2014-03-03 21.36.43.png    
Issue Links:
Duplicate
duplicates SERVER-12950 Ordered write commands in mongos do n... Closed
Operating System: ALL
Participants:

 Description   

Running these two cases shows some unexpectedly huge discrepancy in run time:

db.user.drop();
for (var x = 0; x < 10000; x++) {
    db.user.insert({ x: x });
    if (!db.getMongo().useWriteCommands()) {
        db.runCommand({ getLastError: 1 });
    }
}

raw smoke.py: 4697 ms
--use-write-commands: 8640 ms

db.user.drop();
var bulk = db.user.initializeUnorderedBulkOp();
for (var x = 0; x < 10000; x++) {
    bulk.insert({ x: x });
}
bulk.execute();

raw smoke.py: 4769 ms
--use-write-commands: 305 ms



 Comments   
Comment by Daniel Pasette (Inactive) [ 04/Mar/14 ]

duplicate of SERVER-12950

Comment by Davide Italiano [ 04/Mar/14 ]

https://github.com/mongodb/mongo/commit/24f85cdfdba1db685f4da499d8fcb77385e57da7 fixes the regression, and I'm positive this can be closed, if renctan agrees. You can see that in the screenshot attached.

Comment by Davide Italiano [ 03/Mar/14 ]

Looks roughly the same to me. Let's wait for the other ticket to be resolved and see if this is fixed as well before marking a duplicate, IMHO.

Comment by Daniel Pasette (Inactive) [ 03/Mar/14 ]

Isn't this SERVER-12950?

Comment by Davide Italiano [ 03/Mar/14 ]

I'm able to reproduce the behavior in my mongo-perf testing, on a scenario where empty documents are inserted in batch in a sharded cluster.
It looks like the increasing the size of batch just makes the regression more evident. Simple screenshot attached when batchsize is equal to 10. It gets worse on multithreaded tests, for your information.

Some numbers:
Batchsize<2> : 37540.96 ops/s vs 22362.15 ops/s (1.67x faster)
Batchsize<10>: 82057.41 ops/s vs 22601.14 ops/s (3.63x faster)
Batchsize<100>: 133014.63 ops/s vs 23140.15 ops/sec (5.74x faster)
Batchsize<1000>: 148945.39 ops/s vs 23329.08 (6.38x faster)

It's possible that the size of document could be a significant factor in the test – but I haven't tried to change it.

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