For a while now I have been developing and testing my REST API application using the MongoDB’s free cloud instance. Now, MongoDB clearly states that the free instance is meant for development and testing rather than to be used in production so I went in with the corrisponding mindset.
Being not too far away from deploying the api to production I have started looking into optimizing it and there was an endpoint that was really bothering me with its 700 - 1000ms processing time required. Other endpoints also had respectively rather high fluctuating processing times anywhere between 100 to 400ms.
Out of curiosity, I have switched to MongoDB hosted on the localhost and the processing time of all those endpoints dropped to 30-50ms making it blazing fast in comparison. This experiment has induced some questions in me.
Bearing in mind that it is a free MongoDB instance, is it safe to assume that this dramatic performance difference can be attributed to the free instance?
Should the performance of the free instance be worrisome to me for whatever reason? Are they indicative of something bad done on my part? Or is this just the nature of the free instance, seeing how the localhost db runs way faster?
The production app will use a dedicated MongoDB instance, probably one of the starting ones, like AWS M10. How will the performance compare in relation to the free instance? Roughly speaking, between the fast localhost and the sluggish free instance performance, where would the paid dedicated instance place?
there was an endpoint that was really bothering me with its 700 - 1000ms processing time required. Other endpoints also had respectively rather high fluctuating processing times anywhere between 100 to 400ms
Out of curiosity, I have switched to MongoDB hosted on the localhost and the processing time of all those endpoints dropped to 30-50ms making it blazing fast in comparison.
Just in regards to those values you’ve provided, I am interested to know how they are being calculated? E.g. is this the total time including application processing, network latency and database execution time or just database execution time alone? I presume it’s just the database execution times but please correct me if I am wrong here.
Bearing in mind that it is a free MongoDB instance, is it safe to assume that this dramatic performance difference can be attributed to the free instance?
It would be difficult to say with the information we have here alone. However, please note there are some limitations associated with the M0, M2 and M5 tier clusters. More specifically to the performance, it is possible that either the following limits were exceeded:
Data Transfer Limits
Throughput
You could check with the Atlas chat support team regarding the above limits and if your cluster had exceeded them during the time the testing was performed.
Should the performance of the free instance be worrisome to me for whatever reason? Are they indicative of something bad done on my part? Or is this just the nature of the free instance, seeing how the localhost db runs way faster?
At this point in time I understand your concern based off the values provided. However in saying so, it’s difficult to confirm whether the higher processing times recorded with the workload used in the testing scenarios you’ve mentioned can be attributed solely to the M0 tier cluster.
The production app will use a dedicated MongoDB instance, probably one of the starting ones, like AWS M10. How will the performance compare in relation to the free instance? Roughly speaking, between the fast localhost and the sluggish free instance performance, where would the paid dedicated instance place?
The easiest way to test this out would probably be to test on a M10 instance but I do understand that this may not be the most convenient as it would mean that payment information would be required during the testing duration of the M10 instance. In saying so, Atlas is a database as a service which includes various features and benefits. If you find that hosting locally suits your use-case then this is certainly fine as well
In addition to the above questions regarding the processing times, please provide the following information:
Further details and context regarding the REST API application and associated operations to the MongoDB instance(s)
If the exact same MongoDB version was used in both the local environment and the M0 tier cluster
Forgive me for not providing the necessary specifics. The processing times actually come from Postman, so they are somewhat “dirty” as it is not just pure database queries. Today I launched the paid M10 instance and I am facing what seems to be a similar problem as with the free instance, albeit somewhat milder.
The following is the Postman report for creating a resource on AWS M10. The server is based in a city where I am located and where I am firing the requests from.
That very same request done to MongoDB hosted locally:
I just can’t seem to understand what is causing such an increase. By the way, I have found the following forum post regarding the similar issue:
The response there mentions the reopening of connections being the potential suspect, but I am not sure if this is my case, as I am using mongoose and performing connect() only once (during the start up of the app).
Hi @RENOVATIO - Thank for clarifying those details
I’m not too familiar what “Transfer Start” correlates too within Postman. After a quick google, a postman forum postssuggests that it may be the equivalent to Chrome Dev Tool network metric called Waiting (TTFB) defined as:
Time spent waiting for the initial response, also known as the Time To First Byte. This time captures the latency of a round trip to the server in addition to the time spent waiting for the server to deliver the response.
If I understand the test correctly, it’s measuring everything including network round trip time. In many cases, this is unavoidable since Atlas is hosted in a cloud provider (AWS/Azure/GCP) and the amount of network latency would depend on how good your connections are to those providers. This is the reason why your local MongoDB deployment is so fast: it doesn’t need to contend with network latencies or any network issues.
There is no way to remove this network latency, although you can usually minimize it by:
Selecting the nearest AWS/Azure/GCP region closest to your physical location
And/or upgrading your internet connection speed and bandwidth.
Although some of these may be quite obvious, I’d like to confirm some of the following:
Is the application on the same region as the Atlas cluster?
Is the application hosted on the same cloud provider as the Atlas cluster?
What is the particular operation / application being performed? If so, please provide those details
Is the exact same data set being used?
Is the exact same MongoDB version being used?
(If applicable to your application) - The output of .explain(“executionStats”) for both the localhost and Atlas instances for the operation tested.
I understand the performance time increases may not be solely due to network but the above information should help narrow this down.
