I am currently using a standalone mongodb with high read operations. Since replica sets could provide high read performance, I setup a 3 node replica set on 3 vms with read preference as "secondary preferred". However I could not see any performance improvement, in fact the replica set runs a little slower(~2 secs) than the standalone.The configuration is as follows, 4GB of RAM, 7GB of data, 50 GB of hard disk on all 3 vms and for the standalone db and We are using aggregate queries. I would like to know what could be the real reason for the replica sets to function slower compared to the standalone db.

  • 1
    If you want to improve read performance optimising common queries is a great first step. Adding more nodes on a single server will increase contention for resources and is likely to be more detrimental than helpful. Please edit your question to include an actual aggregation query and some information about the number of documents processed and included in the results. Are all eight queries against the same collection? Does "db is 4GB of RAM" indicate your total RAM or what you've set the WiredTiger cache size to? What are your specific versions of MongoDB server, driver, and O/S?
    – Stennie
    Apr 19 '18 at 7:07
  • Hi @Stennie, thanks for looking in and sorry for the delayed response. Please find the requested information--> 1. Regarding the aggregation query, i believe i am not supposed to share so pls excuse and FYI.. we removed indexes as they increased the execution time rather to decrease it 2. There is only 1 collection against which all agg. queries are running. 3. The total RAM size of the server is 4 GB and the WT cache size is around 1.4gb 4. Mongodb version is 3.4 64 bit and OS is RHEL-7, AvgObjectSize is 632 B, 6.7 documents in total.
    – Kenny
    Apr 20 '18 at 6:49
  • Also kindly reconfirm, if adding more nodes on a single server would be harmful even if we are using VMs.
    – Kenny
    Apr 20 '18 at 6:49
  • Are you able to post a redacted version of your aggregation (variable names changed or at least a general idea of the stages)? My suspicion is that your aggregation queries are fetching a large number of documents and putting pressure on the WT cache. If removing indexes increased performance, these indexes were perhaps unused by the aggregation but contending for cache space. What is the 7GB of data measuring (size of data on disk, db.stats().dataSize, ...) ?
    – Stennie
    Apr 20 '18 at 15:15

I would like to know what could be the real reason for the replica sets to function slower compared to the standalone db.

Replica sets provide high availability and data redundancy, but these benefits are best realized using separate server resources.

With multiple data-bearing replica set members on a single server you are adding contention for the underlying hardware resources (CPU, RAM, disk):

  • Every write has to be replicated and applied by each of the replica set members (which each have their own journal, oplog, and data files), so there will be significantly more I/O as compared to a standalone server.

  • A replica set on a single server will be using RAM to store multiple copies of the same data; a standalone can have more of your data & indexes in the same amount of RAM.

If the reason for your performance challenge is a lack of resources, you should be adding dedicated resources (such as more RAM or faster storage) rather than sharing existing resources.

Note that even with replica set members on multiple servers, secondary reads are not a panacea. For some considerations, see: Can I use more replica nodes to scale?.

Before adding additional server resources, I recommend starting with optimising indexes to support your common queries and aggregations. See: Index Strategies in the MongoDB documentation.


Mongodb Standalone Performs better than Replica Set

As per MongoDB BOL here A replica set is a group of mongod instances that maintain the same data set. A replica set contains several data bearing nodes and optionally one arbiter node. Of the data bearing nodes, one and only one member is deemed the primary node, while the other nodes are deemed secondary nodes.

As mongod is the primary daemon process for the MongoDB system. It handles data requests, manages data access, and performs background management operations.

As per MongoDB Blog documentation here Aggregation pipelines are resource intensive operations – it makes sense to offload aggregations jobs to secondaries of a MongoDB replica set when it is ok to operate on slightly stale data. This is typically true for ‘batch’ operations since they don’t expect to run on the latest data. If the output needs to be written to a collection then the aggregation jobs only run on the primary since only the primary is writable in MongoDB.

  • Hi @Md Haidar Ali Khan, thanks for your swift response. The links provided give us good insights. But in my case, the aggregate queries are performing only reads and they are routed to the secondaries. I suspect something with regards with the VM or the RAM size of the db
    – Kenny
    Apr 18 '18 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.