# Why slower using multiple mongos?

When I use a single mongos like 1.1.1.1:30000, the driver will return in 20ms to find a batch of documents.

When I use 1.1.1.1:30000,1.1.1.2:30000,1.1.1.3:30000,it costs 60ms,three times more to return.(to find the same batch)

And when I use 5 mongos instances, 5 times more.

It's better to use mongos locally, perhaps. But why?

Sorry for my nescience about mongo. What I know is that mongo client is always described some sort of like this

mongoc_client_t is an opaque type that provides access to a MongoDB server, replica set or sharded cluster.

Which can't explain what happened and why mongo driver costs more time as using more mongos node in uri like this:

mongocxx::client client_;
client_.reset(new mongocxx::client{mongocxx::uri{"1.1.1.1:30000,1.1.1.2:30000,1.1.1.3:30000"}});
...
auto collection = (*client_)["db"]["col"];
auto cursor = collection.find(filter_builder.view(), find_options);
...


PS: All mongos refer to the same cluster.

I'm now trying to debug the latest driver.

My drivers in this case:

mongo-c-driver: #define MONGOC_VERSION_S "1.5.1"

mongo-cxx-driver: #define MONGOCXX_VERSION_STRING "3.1.1"

network & latency time:

1.1.1.1,1.1.1.2,1.1.1.3 all in the same room

latency: ping localhost 0.03ms ping 1.1.1.2(from 1.1.1.1) 0.2ms

batch size: about 100 find{"uid":{"\$in":[1,2,3...,100]}} uid is an ensured index.

• another explain about how driver execute commands on a mongod, replica set ,or a shard cluster\single mongos SERVER SELECTION – Chen Si Yi Sep 24 '18 at 18:26
• What's the network latency? How big is your batch of documents? If it's small, the overhead of network communications with each node, as well as aggregation of results, might be significant compared to the time it takes to read data. – mustaccio Sep 24 '18 at 19:43
• What specific driver version are you using? Do you see the same timing on every query, or only the first one? Is the timing always 20ms per mongos listed? Generally the driver should connect to the first available mongos listed in your connection string so linear growth seems unusual. – Stennie Sep 25 '18 at 0:36

I have been troubled in this problem so long,and sorry to say that this does not recur all the time.

First, according to official documents, connections are usually established and authorized in the initiation.Then I traced the program to ensure it. Only one random server id is needed in an query, if no error.So liner ascending latency shall never happen as server number increase.

I wrote a test this week, and the result is that no matter how many mongos server are listed in the uri, the latency of the query are randomly distributed in between 3ms to 30ms. Extreme cases happened when network got worse.

This is totally different to the case when I asked this question.So I have to blame it on these changes:

1. More mongos server are available now ,and queries are separated.
2. Most clients are using single mongos server now, so less tcp connections exist and network is better.
3. We improved our program and queries from clients are less and lighter.


Actually , except from the liner ascending latency, some queries returned in above 16 second two weeks ago.

I guess that liner increased latency is just a form of performance degradation.