very slow writes with w=1 and j=false

[flora91k]

Hello, I am benchmarking MongoDB with YCSB and while I get very fast reads, the write operations are up to 10 times slower in many cases.. I am using w=1 and j=false. Do this options involve the disk at all? I don't exactly understand what "propagated" means in the documentation that states: "Requests acknowledgement that the write operation has propagated to the specified number of mongod instances"

Can someone please explain what happens in this case of write configuration? Is the disk involved at all? What could cause such a big difference on write vs read performance?

 

[Kevin Adistambha]

Hi,

Hello, I am benchmarking MongoDB with YCSB and while I get very fast reads, the write operations are up to 10 times slower in many cases.. I am using w=1 and j=false. Do this options involve the disk at all?

I don’t exactly understand what “propagated” means in the documentation that states: “Requests acknowledgement that the write operation has propagated to the specified number of mongod instances”

Can someone please explain what happens in this case of write configuration? Is the disk involved at all?

The settings for w=1 and j=false is a write concern setting, which governs how durable the write should be before it is acknowledged by MongoDB. Specifically:

• w is the number of mongod instances that needs to acknowledge the write. MongoDB is designed as a distributed system, and the w option specifically refer to the Replica Set. w=1 means that only the Primary must acknoledge the write. w=2 means that the Primary and one Secondary node must acknowledge the write, and w=majority means that the majority of the voting nodes in the replica set must acknowledge the write.

• j is the journal option. true means that MongoDB will acknowledge the write when it has been written to the journal. Setting j=false means that MongoDB will acknowledge the write before it is written to the journal.

Regarding your question, w=1, j=false means that the write operation will be acknowledged by a single server (or the Primary in a replica set), and will acknowledge the write before it’s written to the journal.

For more information and examples regarding write concern, please see:

• Replica Set.
• Write Concern

What could cause such a big difference on write vs read performance?

Hard to say since there are many factors that are involved in performance benchmarking that could lead to lower than expected results, for example:

• Resource contention in the machine running MongoDB (more than one resource-intensive processes in the machine running MongoDB)
• Under-provisioned hardware (small memory, slow disk, etc.)
• Sub-optimal settings for MongoDB (see the Production Notes for more information)
• The MongoDB version used (there may be performance issues fixed in newer versions)
• The schema used during testing, which may be suited for read operations and not for write operations
• The read/write mix being tested (50/50, 95/5, etc.)

Best regards,
Kevin

​