Mongoose execution time increased 2 times after upgrading 4 to 6 #11380
Comments
|
Nice Issue. I do love performance investigation tasks. So first of all thank you for your script. Especially because you have an example regarding MongooseArrays, because I think they are a big performance eater. But it can be an issue on multiple levels. E.g. We use Proxy for MongooseArrays, which can have a performance hit. We could use your sample script to --inspect and see where the most cycles are wasted, use deoptigate to determine if we have somewhere heavy deoptimizations and using 0x to look on flame graphs. But then again we could have usual performance tradeoffs. E.g. I think using Arrays as Document Attributes slows mongoose heavily down, because of the Proxy. But there are some potential perf improvements existing.e.g. mongoose/lib/types/array/index.js Line 98 in 5c13dcb Instead of passing the proxy we could directly refence the internal Object and see if it is improving the performance. Or we could check if we can use instead of classical for loops over the proxy the built in forEach and map methods to avoid crossing the Proxy layer over and over. Maybe the issue is not the Proxy but something else, like heavily creating useless intermediate variables, which have to be later garbage collected and they sum up heavily and as such slow down the perf. I have some benchmarks were i have like 70% of runtime wasted in the garbage collector. Not nice. But these are some ideas... |
|
I checked that with a git bisect. The issue first time the performance heavily broke down was with Commit d9c2a46 where mongooses upgraded mongodb native driver from 3.0.2 to 3.0.3. We maybe had other performance degredations, but it is quite too late to figure this out anymore without a lot of heavy lifting. mongodb native driver was just too much heavily changed, so that I can not figure out where mongoose maybe added performance degredations additional to the performance degredation implemented by the native driver. |
|
Hi, thank you for answer! I'm glad to see that there is a hope to fix that issue (I've spent many hours to find out how I broke ours system performance). Using
|
|
You can have a look at this |
|
First of all the mongodb dev team is very slow. So probably this PR will not land very soon. My advice is, that you should think what you want to prioritize: security or performance. Other than that I can not really say, that the underlying performance will improve in the next months. Like I wrote: mongodb team is slow. My PR will foreseeable not be accepted, because they want first benchmarks etc.. Thats quite abstract requirement, so probably they wont have a near future. If you are totally crazy about performance, than have a look alternatives from @marcj in https://github.com/deepkit/deepkit-framework/tree/master/packages/mongo |
|
Thank you for so detailed answer, very appreciate. I can't believe that thouthands of mongodb users are facing with 2x perfomance degradations since mongoose@4! |
Actually there are millions, and the vast majority does not care as they are dead hobby projects/no business, are one of the 90% of startups that fail, have very low traffic, or have other reasons to simply not care about performance. High performance in web affects only the upper 99 percentile high-revenue, high-traffic, or some edge case businesses, some even optimise for that without actual need aka premature optimisation. There is mostly no point in providing an expensive high performance implementation of something if the target audience is for 99% users that can't care less if you have 10ms response time or 100ms, except if the program is otherwise too slow or you have a fetish for efficient software. If you have however a need though then performance is suddenly worth tons of money - then you should look for the right tools/vendors. So I'm not surprised that no one cares if they have such a performance drop in a OSS library that literally never cared about performance since the very beginning. |
…ere's no validators to run Re: #11380
|
Thanks for the detailed benchmark @ekorolevanyrun . 94d77c2 makes some substantial improvements by avoiding running validation on array elements if there's no validators to run. Before we'd have O(N) checks for "are there any validators to run for Before: After: For comparison's sake, here's what I get if I just do There's still some overhead left, but considerably less than before. |
|
I also think that we can not improve it further as it is clearly a driver performance bottleneck. |
|
That's true. I'd like to minimize the overhead relative to the Node driver, and there's still a decent amount of overhead that we can shave off. But given that some of the issue comes down to bson serialization, there isn't much we can do about that unless we use a custom version of bson. |
|
@ekorolevanyrun that's something we'll consider. However, is there anything blocking you from using |
|
@vkarpov15 , nothing blocks us except the fact that I don't know which package should be used to substitude :) So, what is needed is add in my package.json something like this, right? |
|
Just want to add that you should do performance tests. I tested bson serializing and in bson it was fast but using native driver etc. I maybe did not have the right benchmark, but it was actually still slow. So please bechmark. |
|
Added some more perf optimizations, we're about as close as we're going to get to the MongoDB driver without using @Uzlopak 's bson improvements. Hooks and cloning take up virtually the entire time difference between native driver and Mongoose right now as far as I can tell. |
|
Hi! I had to pospone this task, but there was some free minutes and I made fresh perfomance tests. Mongodb-driver 4.9.0 and mongoose 6.5.2 is used. As for previous tests some data is generated: then I made 10.000 operations ResultsMongodb driver: Mongoose@6.5.2: Mongoose@4, by the way: So, there is still an impressive difference between mongoose insertOne and clean mongodb-driver insertOne. |
|
I took a look and it looks like the performance got much better in 6.2.7: With latest 4.x: With 6.2.1: With 6.2.7: With 6.12.3: With 8.0.1: So try upgrading to 6.2.7 to see if that works better for you. In the meantime, we'll investigate and see how we can improve this performance. |
Perf improvements when creating arrays of primitives
Do you want to request a feature or report a bug?
Probably bug
What is the current behavior?
Execution time increased after upgrading mongoose (4.13.21 -> 6.2.1) in 2 times
If the current behavior is a bug, please provide the steps to reproduce.
We have 2 mongodb replicas (primary and two secondary ones). You can reproduce the problem with a simple script:
You can replace
await record.save()toawait slowsaveModel.deleteOne({})and the results doesn't change. It doesn't matter which function do you use, it seems execution time has been increased for all methods.What is the expected behavior?
Here are result of script with mongoose@4.13.21:
Result with mongoose@6.2.1 (note that it is the same script with the same databases):
What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.
Node: v14.18.3
MongoDB server version: 5.0.6
Mongoose: 4.13.21 & 6.2.1
The text was updated successfully, but these errors were encountered: