-
Type:
New Feature
-
Resolution: Won't Fix
-
Priority:
Critical - P2
-
None
-
Affects Version/s: 2.6.1
-
Component/s: Sharding
-
None
-
Sharding
Shows up as a performance degradation for applications that use w:0 and getLastError in a sharded environment when going from 2.4 to 2.6:
To reproduce: create a collection, mongodump, mongorestore via mongos to single-shard cluster (single mongod, single config server). Doesn't seem to matter if collection is sharded or not.
Here are some numbers for one data set:
2.4.10, standalone 26s 2.6.1, standalone 26s 2.4.10, 1x shard, 1x mongos, sharded 58s 2.6.1, 1x shard, 1x mongos, sharded 352s
Another data set, showing that sharded or unsharded shows same degradation:
2.4.10, standalone 5s 2.6.1, standalone 5s 2.4.10, 1x shard, 1x mongos, unsharded 5s 2.6.1, 1x shard, 1x mongos, unsharded 45s 2.4.10, 1x shard, 1x mongos, sharded 8s 2.6.1, 1x shard, 1x mongos, sharded 52s
- is duplicated by
-
SERVER-22260 Support async w:0 mongos writes
-
- Closed
-
- is related to
-
TOOLS-159 Tools should use (batch) write commands
-
- Closed
-
- related to
-
PYTHON-1069 command not listening to writeconcern
-
- Closed
-