Question

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"}});
...
mongocxx::read_preference read_preference;
read_preference.mode(mongocxx::read_preference::read_mode::k_secondary_preferred);
find_options.read_preference(read_preference);
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.

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top