Skip to content

Parse.com vs Parse Server - Slower Queries #1564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
jobacao opened this issue Apr 20, 2016 · 3 comments
Closed
2 tasks done

Parse.com vs Parse Server - Slower Queries #1564

jobacao opened this issue Apr 20, 2016 · 3 comments

Comments

@jobacao
Copy link

jobacao commented Apr 20, 2016

For implementation related questions or technical support, please refer to the Stack Overflow and Server Fault communities.

Make sure these boxes are checked before submitting your issue -- thanks for reporting issues back to Parse Server!

Environment Setup

Environments

  1. parse.com with mlab mongo
  2. parse server 2.2.7 with mlab mongo

Steps to reproduce

Query 1) and 2) with a where, limit and order clause. Example:

/classes/albums
{"where":{"artists":"Band"},"limit":100,"order":"-releaseDateValue"}
  1. parse.com generates a query that takes 524 ms
  2. parse server generates a more complicated / nested query that takes 1134 ms

Logs/Trace

  1. parse.com query
{ $query: { artists: "Band", _rperm: { $in: [ null, "*" ] } }, $orderby: { releaseDateValue: -1 }, $maxScan: 500000, $maxTimeMS: 29000, $comment: "queryhash:89c4fc26d1926094198e827388a261e8" } planSummary: COLLSCAN, COLLSCAN ntoreturn:100 ntoskip:0 nscanned:0 nscannedObjects:128120 scanAndOrder:1 keyUpdates:0 writeConflicts:0 numYields:1001 nreturned:51 reslen:992098 locks:{ Global: { acquireCount: { r: 2004 } }, MMAPV1Journal: { acquireCount: { r: 1002 } }, Database: { acquireCount: { r: 1002 } }, Collection: { acquireCount: { R: 1002 } } } 524ms
  1. parse server 2.2.7
{ $query: { $and: [ { artists: { $all: [ "Band" ] } }, { $or: [ { _rperm: { $exists: false } }, { _rperm: { $in: [ "*" ] } } ] } ] } } planSummary: COLLSCAN, COLLSCAN ntoreturn:100 ntoskip:0 nscanned:0 nscannedObjects:128120 scanAndOrder:1 keyUpdates:0 writeConflicts:0 numYields:1001 nreturned:51 reslen:992098 locks:{ Global: { acquireCount: { r: 2004 } }, MMAPV1Journal: { acquireCount: { r: 1002 } }, Database: { acquireCount: { r: 1002 } }, Collection: { acquireCount: { R: 1002 } } } 1134ms
@blacha
Copy link
Contributor

blacha commented Apr 20, 2016

This may be unrelated, but it looks like you don't have a index on artist, the plan being COLLSCAN and nscannedObjects being soo high seems like its doing a full table scan.

Are these two queries being run against the same database in mlab?

@jobacao
Copy link
Author

jobacao commented Apr 20, 2016

The two (parse.com/parse server) queries are against the same mlab db. Any ideas on why parse.com and parse server are generating 2 different queries?

@drew-gross
Copy link
Contributor

Parse Server is missing some optimizations present in Parse.com. We'll continue to improve perf over time :) thanks @blacha for fixing one of the issues from here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants