What is the recommended value for the serverSelectionTimeoutMS setting for Atlas?

The nodejs driver default serverSelectionTimeoutMS is 30s. But for some scenarios, like inside AWS Lambda, waiting 30s is not ideal.
According to this documentation we should set it to 15s:

Lower the serverSelectionTimeoutMS to 15000 from the default of 30000 . MongoDB elections typically take 10 seconds, but can be as fast as 5 seconds on Atlas. Setting this value to 15 seconds ( 15000 milliseconds) covers the upper bound of election plus additional time for latency.

(also is strange that this is only mentioned for the C driver … while I would expect to be a setting mostly unrelated for the driver but related to the server instead)

Mongoose documentation instead suggest to use 5s for Lambda. But I have noticed some random connection timeout error (MongooseServerSelectionError) when using 5s with an Atlas cluster.

Can you please confirm that 15s should be a good default value for Atlas connections?

1 Like

Hi @Davide_Icardi,

Welcome to the community :wave:

According to this documentation we should set it to 15s:
Lower the serverSelectionTimeoutMS to 15000 from the default of 30000 . MongoDB elections typically take 10 seconds, but can be as fast as 5 seconds on Atlas. Setting this value to 15 seconds ( 15000 milliseconds) covers the upper bound of election plus additional time for latency.

The 15000ms setting mentioned in the docs is only applicable to some drivers (notably C in single threaded mode) but not others, so please follow the instructions for the applicable drivers if available. More specifically, the 15000ms value provided is to allow for less interruptions between replica set failovers for certain drivers in single thread mode.

Mongoose documentation instead suggest to use 5s for Lambda. But I have noticed some random connection timeout error ( MongooseServerSelectionError ) when using 5s with an Atlas cluster.

Mongoose’s connection settings (including the serverSelectionTimeout & serverSelectTryOnce ) should follow the recommendation for the node.js driver.

In addition to the above, you may find the Best Practices Connecting from AWS Lambda documentation helpful which also notes the below recommendation:

Define the client to the MongoDB server outside the AWS Lambda handler function.
Don’t define a new MongoClient object each time you invoke your function. Doing so causes the driver to create a new connection pool with each function call.

Lastly, depending on your use case and environment, you may wish to consider using the Atlas Data API which allows for read / writes using simple REST calls. However, please note that this is not yet GA and is currently in preview.

Hope this helps

Regards,
Jason

3 Likes

Thank you @Jason_Tran for the info.

But I’m not sure to have understand what value should I use for serverSelectionTimeoutMS, an Atlas cluster and a nodejs driver running indide AWS Lambda.

Do you suggest to use 5s as written by Mongoose or leave the default 30s?

Hi @Davide_Icardi,

Do you suggest to use 5s as written by Mongoose or leave the default 30s?

Other than the default value of 30s, there’s not really a “recommended” value for serverSelectionTimeout. There are use cases that allows for a lower number if a client wants to fail fast and throw an error if it cannot see a suitable server within 30s, and vice versa there are also use cases that needs a higher number to ensure a connection is made to the servers and the client is willing to wait.

Thus if you find that you want to fail fast and not wait 30s before the driver throws an error, you may be able to set a lower number. This number would be different for different use cases, so you should try different numbers according to your specific circumstances (e.g. network latency, your topology, your tolerance to drivers throwing connection errors, etc.)

Regards,
Jason

1 Like

cani set this number to NUMBER.MAX_VALUE, to make sure my client keeps trying to connect to my db server when it gets disconnected?

Hi @Ramesh_Ravi
From my experience as a mongodb user, I don’t think it is a good idea to use very large timeout, because it can hide the connection problems with other timeouts.
For example: most http server/api gateway as some kind of timeout (30, 60, …). If you set the serverSelectionTimeoutMS larger than that timeout you can reach it without really understanding what is going on. I prefer to see a mongodb connection error, and eventually handle some kind of retry, that just receive a generic timeout or worst a very very long operation that “never” end.

2 Likes