[JAVA-1339] Performance degradation when switching from 2.4.x to 2.6.x with newer Java driver Created: 17/Jul/14  Updated: 11/Sep/19  Resolved: 23/Jun/15

Status: Closed
Project: Java Driver
Component/s: Performance
Affects Version/s: 2.12.0
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Remon van Vliet Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: TR
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 2_11_driver_against_2_6_server.txt     Text File 2_12_driver_against_2_6_server.txt    

 Description   

We're noticing a pretty dramatic decrease in performance on 2.6.x when using the 2.12.x Java drivers rather than the 2.11.x ones. I'm adding this here because it was pointed out to me this is likely due to the newer Java driver using a different code path for writes in which case this is a performance issue related to that code. If this is incorrect feel free to move to the java driver project.

I have attached to output of mongostat for two test runs. One is 2.11.x Java driver versus 2.6.x and the other uses 2.12.x Java driver.

There is about a 10-20% difference in raw performance depending on the operation being executed.

Given the fact that we have to provision capacity for peak usage for our customers this could affect our net hosting costs so it would be good to have a quick resolution to this issue.



 Comments   
Comment by Remon van Vliet [ 14/Aug/14 ]

Hi Jeff,

My apologies, I thought I had already replied. The test above was run with {writeConcern :

{w : 1}

}

Comment by Jeffrey Yemin [ 12/Aug/14 ]

Remon,

Just checking in once more to ask about the write concern that your application is using, so we can make some progress on this issue.

Regards,
Jeff

Comment by Robert Moore [ 02/Aug/14 ]

Not sure if this is the Java driver or not but the write concern is not (w:0).

If you look at the 2.11 mongostat you will see a large number of commands being counted for the getlasterror commands. That only happens for (w:1) or better.

Comment by Daniel Pasette (Inactive) [ 01/Aug/14 ]

Though the driver did change to handle the new write commands introduced in 2.6, the old code path is still used in the new driver for fire and forget writes (w:0).

As this does not appear to be a SERVER issue at this time, I'll move this ticket to the JAVA project where the performance issue can be addressed.

-Dan

Comment by Remon van Vliet [ 18/Jul/14 ]

1) The issue seems to occur regardless of setup (repset and standalone were tested). The output is from a stand-alone single instance test.
2) w = 0
3) No
4) All of the above. The log posted are from very simple test inserts, queries and updates (save({a:[X]}), find({a:[X]}) and so on
5) I'll see what I can do. Our time to investigate this is limited.
6) See above.

EDIT : Had some odd test results here but those were likely due to a changed default write concern.

Comment by Thomas Rueckstiess [ 17/Jul/14 ]

Hi Remon,

To diagnose that kind of performance issue I would need some additional information.

  1. What setup is this? Sharded? Replica Set? Stand-alone node?
  2. Are you using any write concern for your operations? (e.g. w=0, 1, majority)
  3. Are you using the bulk API in the java driver for 2.6 as outlined e.g. here ?
  4. What kind of operations are you running in this test? I can see queries, inserts, updates, deletes, but can you give more details? Are queries, updates, etc indexed? Ideally, are you able to share the test code?
  5. Can you please run the tests with log level 1 or higher ( mongod -v or via db.adminCommand('setParameter': 1, 'logLevel': 1) ) and attach the log files of both runs to the ticket?
  6. To distinguish if this is a driver or server problem, have you tried running the new 2.12 driver against a 2.4.x mongod? If so, what is the result of that test?

Once we have that information we can proceed with the diagnosis.

Thanks,
Thomas

Generated at Thu Feb 08 08:54:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.