It would work under the hood by executing 3 queries:
1- Book.findOne(...)
2- Author.findOne(...)
3- Review.find(...)
I've run the script below to have more understanding of how the populate queries are executed.
Turns out populate queries are executed in sequence (e.g., we wait for author results to come back from the database, then we start finding reviews).
This approach would prevent slow trains to slow the whole application down, however, if an application makes few requests and would rather make specific endpoints faster, using populate would make things slower.
Also, the slow trains issue would become a problem only if all the populates are slow, if one or two are slow that would mean there are still remaining sockets for MongoDB to channel the other queries on, given the default of 5 sockets by MongoDB, we could also change the default/recommend that people use 10~20 in production which would likely mitigate the risks of slow trains and give better performance.
I think we should:
Make this clear in the docs.
Offer an option to mongoose.set('populateInSequence', false); which defaults to true, then we can discuss further what that default should ultimately be.
Offer an option to set populateInSequence: false for specific queries, which could be useful for people wanting specific endpoints to be as fast as possible, even if it's going to cause slow trains in other areas of the application.
I'd also like to create a simulation of a typical application and compare performance between parallel/sequence populate behavior, any suggestions on the experiment constraints to make it unbiased as much as possible are welcome.
Currently, when we do the following populate:
It would work under the hood by executing 3 queries: 1-
Book.findOne(...)
2-Author.findOne(...)
3-Review.find(...)
I've run the script below to have more understanding of how the
populate
queries are executed. Turns out populate queries are executed in sequence (e.g., we wait forauthor
results to come back from the database, then we start findingreviews
).This approach would prevent slow trains to slow the whole application down, however, if an application makes few requests and would rather make specific endpoints faster, using
populate
would make things slower.Also, the slow trains issue would become a problem only if all the populates are slow, if one or two are slow that would mean there are still remaining sockets for MongoDB to channel the other queries on, given the default of 5 sockets by MongoDB, we could also change the default/recommend that people use 10~20 in production which would likely mitigate the risks of slow trains and give better performance.
I think we should:
mongoose.set('populateInSequence', false);
which defaults totrue
, then we can discuss further what that default should ultimately be.populateInSequence: false
for specific queries, which could be useful for people wanting specific endpoints to be as fast as possible, even if it's going to cause slow trains in other areas of the application.I'd also like to create a simulation of a typical application and compare performance between parallel/sequence populate behavior, any suggestions on the experiment constraints to make it unbiased as much as possible are welcome.
Thoughts? @vkarpov15 @IslandRhythms @ahmedelshenawy25
Output