parse-server: Parse Server periodically is getting slow
- parse-server version 2.7.4 (Azure on a Standard_B4ms)
- mongoDB-server version 3.4.14 (Azure on a separate Standard_B4ms)
I have an iOS & Android app, with LiveQuery (set on the parse-server’s VM) that’s being used a lot for chatting, where usually there are ± 50 simultaneous users. The thing is, after a few hours of continuous usage, the server’s cloud code responses are getting REALLY slow! Not just from a specific one… all cloud functions!
I’m using screen to run the parse server. So I found that if I restart the parse server (not the vm), the app is getting back to normal.
I also have logs enabled at all times. (just mentioning it in case it could be the issue)
I can’t understand why this is happening! Any ideas?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 25 (14 by maintainers)
I have actually done everything @georgesjamous suggested! Our chat is now powered by Firestore (he didn’t suggest to go there, but to separate the live server from the app server), we just started using Redis to cache pretty much anything and the app is now clustered!
I can say with much confidence that the server feels noticeably lighter and faster! I don’t know though how much traffic we can handle!
@Samigos I believe you should always leave at least one (or depending on your needs) CPU core
os.cpus()for the system processes.Also, you don’t need pm2 to run parse in cluster mode. There’s a —cluster option on parse-server CLI.
@Samigos i think you should try what flovilmart suggested.
Some additional notes: There are lots of stuff that should be taken into consideration before you considering this as an issue.
First off, Yes, it’s far better to have LiveQuery on a separate server, try that. Also, I am not sure how much RAM or CPUs your Azure instance has, but if you are running everything (custom cloud logic + live query + accessing the via SDKs) on a single NodeJs instance, then I am sure the problem lies there. Since most of these operations will be queued-up/throttled in node. Secondly, the amount of Data in/out of your instance need to be considered also, for example, what does your custom cloud code logic do ? how many calls ps is each user doing additionally to LiveQ? How many objects are you returning in a single query ? (Tip: keep it low, cache on user devices) In other words, if you are doing a bunch of additional requests concurrently with LiveQ all running on the same instance then yes, your problem is to be expected 😃
Look how I think your debugging should go, 1- Split LiveQ from your main server (test if this speeds things up a bit) 2- Run Parse clustered. To the N-1. N is the number of cores your CPU has. (< 2 cores one instance, like you are doing now. 3 cores run 2, and so on) (test if this speeds things up a bit) 3- Start using Redis Cache, this will free up some memory if you have lots of Roles or 5+ levels deep) (test if this speeds things up a bit) 4- debug your code, how many request are you doing per user ? what does your cloud code do ? Plus: I turn off console logging for production, I use a custom logging adapter, but i guess you can edit this somehow here Line44
Many different things could cause your server to slow down if after doing 1,2,3 the problem remains, then i think this could be considered an issue with parse-server.
You should probably run a profiler attached to your process or an APM that will help you quantify how slow.