Parse server > 3.0.0 is VERY slow for count operations

[SebC99]

Issue Description

With Parse server 3.0.0 everything is going fine, while with Parse server 3.1.1 & 3.1.2 (I haven't test with 3.1.0) count operations are very very slow.
It's immediately visible in Parse Dashboard, as the dashboard tries to display the count of each class (we have around 15 classes plus the parse ones), and it fails to do it, with most requests ending in timeout (especially the ones for the 'big' classes with more than 5M rows).
To be more precise, with Parse Server 3.0.0 those counts appear instantly.

Steps to reproduce

Open the Parse Dashboard on a server with 3.0.0 and compare it with a Parse Dashboard on a serveur with 3.1.1 (and lots of rows)

• Server

  • parse-server version: 3.1.1 & 3.1.2
  • Operating System: AWS ELB

• Database

  • MongoDB version: 3.6
  • Storage engine: wiredTiger
  • Localhost or remote server? Atlas

[acinader]

Could you do a git bisect to find the commit?

[dplewis]

@acinader That’s a cool trick

[SebC99]

@acinader & @dplewis not that simple to do... I have to patch parse-server each time and release a fork without the .nvmrc file which causes npm issues with other node version.
Then I need to upload the fork on github, link it from my server code, and deploy it... So it's a bit long to do so for each single commit (there's a lot of them). I'll do my best

[SebC99]

and it's not visible on our dev server, as we don't have enough rows in our classes :(
I'll try to import millions of lines later

[dplewis]

@SebC99 do you care about the count for 15 million rows? Maybe we can disable count per class.

I don’t see any commits that would affect count operations.

I’m interested in the issue you have with .nvmrc file

[SebC99]

I fully agree as I really don't care about the counts, but it could be the symptom of something else.

[SebC99]

As for nvmrc it fails the automatic npm install of AWS elb with other node versions

[dplewis]

Did you update the node version of your elb to 8.11?

[SebC99]

No we use 8.8.1 in one environment and 10.13.0 in another.
Depending of your Amazon Linux version you can't always have all nodejs version

[stream129]

I have the same problems. I found out that the problem appeared after #5025. The count method in the node-mongodb-native library has been deprecated, but the countDocuments replacement method works completely differently.
Unlike the old count method, the countDocuments method uses aggregation in the DB query. Unfortunately, at the moment, MongoDB does not use indexes for grouping for the aggregation framework. This causes countDocuments to always scan all documents.

[SebC99]

@Stream1988 nice catch! Then using estimatedDocumentCount when there's no query in parameters, and 'countDocuments' when there is would be a better solution?

[stream129]

@SebC99 Maybe yes. Unfortunately, my knowledge was enough just to find a problem. How better to fix it - I do not know. For my server, I simply returned the old count method back and do not pay attention to the deprecated warnings.

[flovilmart]

Long story short, do not rely on mongo counts, they are ineffective. If you want to have a compatibility method, where we’d use the old estimated count instead, you could well open a PR

[SebC99]

@flovilmart you're right and we don't. But the dashboard is... And is now unusable.

[johanarnor]

Just to weigh in as well, since we also experienced the same issue when testing with Parse 3. The dashboard actually brought down the DB for a couple of minutes, since we had missed to configure maxTimeMS in parse-server.

So I agree with @SebC99 (with my basic MongoDB knowledge) that a solution would be to simply use estimatedDocumentCount, when the query is empty, since it ... wraps the count command.

We don't have an upgrade to Parse 3 on our roadmap atm, otherwise I would have opened a PR.

[ghost]

We had the same issues for our production's Parse Server, since whenever we used Parse Dashboard it caused performance issues for our API's.

As a temporary solution I first disabled the fetching of counts in a fork of parse-dashboard, so that we could at least use the dashboard without slowing down our API's.

However, I've now created a PR for this issue at #5264. For the PR I've changed so that if no query is specified when performing a count, then the estimatedDocumentCount method is used instead of countDocuments.

I'm not a MongoDB expert so I'm unsure if fetching the estimated count could cause any issues for Parse. However, it should at least fix the issue with Parse Dashboard fetching counts for large classes.

[flovilmart]

This is reasonable that this was the original behavior exhibited by mongodbz

[dplewis]

Closing via #5264