Like in the title, experts of parse server, what advice can you give me to increase parse server performance, Parse server has a lot of options (which I dont know what are they for or what they do).
What things should I do before going production?
I also opened another thread because I wasnt satisfied. (But I dont have production experience so maybe results are normal).
So advices I will get here will help me. Many thanks.
edit: This question is not about my other thread. I have 2 general question for parse.
1 - What should I do to increase performance? 2 - What should I do before going production?
1 - You should create indexes on database. This may sound weird. But for the people who just started and has no database background this is new. I learnt this from this forum. Before that, I didnt even know there was a thing called indexes. First step of increasing performance is creating indexes.
2 - MongoDB can use only one index for query. When I first started to create index, I created a single index for every field. I thought mongo will look first index. then look second index etc⌠But It doesnât work like that. You should create compound index that includes multiple fields.
3 - NodeJS is single threaded application. Basicly this. NodeJS canât take advantage of multi cores. If your server has 8 cores but you stated your parse server with npm start or something similar, parse will use only one cpu core. To surpass this, there is cluster mode in NodeJS. Its basicly running multiple nodejs app in same machine(generally equal to CPU Core count). And there is a library to handle this. Itâs called PM2. It takes care of you app.
These are the basics I learnt. They may sound very begginer to you. Like âeveryone know theseâ but truth is I didnt know so there may be someone like me. And there may be wrong information in my message. Or half wrongs. Iâm not a CS graduate. I code in my free time because I love coding. And these are the advices I give to beginners like me.
Thatâs a good question which has been touched many times over the years in various threads.
Itâs another aspect of the ambivalence of Parse Server. While Parse Server is designed to be accessible also for beginners, open sourcing it has increased the required expertise to run a production-fit app.
Generally, there are 4 performances areas to consider:
database (e.g. queries, indices, data scheme, server resources, sharding)
server (e.g. instance resources, disk throughput)
app (e.g. parse server code base, nodejs specifics, parse server cache config, multi-core usage, disk ops, client - server interaction, custom cloud code)
network / infrastructure (e.g. load balancer, network bandwidth between components, geo-distribution of resources)
Each of these areas has 2 dimensions:
momentary performance (when everything runs fine)
historic performance (considering downtimes, e.g. due to malicious attacks, misconfiguration, component failure)
Each of these fields can go deep into details, hence they are often allocated to distinct roles / teams in organizations. It can be challenging for full-stack developers and âone-person showsâ to keep up with all these aspects.
I think it would make sense to compose a document over time that lists the âwhat I wish I knew when I startedâ things to consider for each field. It would be the logical document necessary to keep Parse Server easily accessible for beginners even as it is open source now.
There are obvious recommendations such as keeping database field names as short as possible, because it impacts data transfer costs when scaling. But there are many obscure aspects such as choosing a TLD with low DNS latency for the server endpoint, because it impacts connection speed from client to server.
Maybe you can begin by listing what you âwish you knew when you startedâ and others can add to that list easily here and we eventually compile a document as part of the Parse Server guide.
Really appreciate such an active community behind this amazing project!
Is there already a contemporary âexpert guideâ for novice developers to set up a complete app for a production environment?
Have tried my hand at setting up the complete stack (parse server/dashboard/database) multiple times while following bits of information from all over. But no success, only stress
Could really use some expert guides or options like One-Click-Deploy for some of the major Infrastructure providers.
Please see the Community Links. We do have a page with One-Click deployment buttons, I just canât seem to find it right now, it should be on GitHub IIRC.
I would get great value out of any such âproduction workflowâ or âadvanced configurationsâ such as these. The opening bullet lists give a good indication of subject matters to understand.
For example, I have been using AWSâ ECS with my current development work, and expect to retain this platform using an Infra as Code (IaC) implementation for rapid deployment (CI/CD), integrating with other Amazon services, such as using their ELB with inclusive Certificates (to provide encryption, as well as enabling sharding / scaling for performance, etc).
Can I start with the database:
I presume we (the developers) are expected to perform the MongoDB configurations? We get nothing from Parse itself?
Is it principally indexing the would provide the most performance boost?
Is this mostly dependent upon the data schema / structure? For example, denormalizing the data structures to allow for better read performance (i.e. put all rows / records into the DB, then use appropriate filters to limit the returned results, rather than multi-table (RDBMS) structures that need to return to the DB on multiple occasions to complete a single query.) Or is there a standardised pattern to follow?
Hope it makes some / any sense - I know it is a large and wide subject⌠Trying to kick things off.
I would like to add a few more things here and also I want to note here: All my requests to parse server is cloud code request.
From my observation:
1 - Parse server is cpu hungry. Generally speaking cpu will be bottleneck. Monitor your server cpu usage and check this.
2 - Parse doesnât need too much ram. 500Mb per parse server would be more than enough. I have server with 2.5gb ram and 4 cpu. 500Mb for OS and 500mb for one parse instance. I run 4 parse server in the same machine. Works great.
3 - Redis Cache decreases performance. I was expecting that if I use redis cache (redis installed in seperate machine) performance would increase. Because you know redis will reduce requests to database and this means more performance. But It didnt worked like that. My server performance decreased by 50%
4 - Simple MongoDB server will take you too long. I realized this today. I was doing some benchmark tests to see How my parse server will behave under some stress. I didnât like the results. I monitored my database server. When I was doing some benchmark test, My database servers CPU usage went to over 90%. And I tought âThis is my problemâ. My database server was 2cpu and 2gb ram. I rescaled this to 4 cpu and 8gb ram. But when I re-do benchmark, my performance didnt increase. Because database wasnât the problem. So I rescaled my server to 2gb ram and 2 cpu. Then I found my problem(See next). And when I solved it my request per second got doubled even my database specs stays same. A well indexed database with SSD disk will take you too long.
5 - You have to scale parse server If you wanna keep the performance. From my observation, single parse server can handle 20-25 request per second(Cloud code request, didnt test normal requests, This value also depends on what you do on your cloud code. I do 4 queries and return array of parse objects. This number can be as high as hundreds if cloud code is simple enough). So if your server gets20 request per second, parse server can feed them. But If your server is getting more than that for example you have one parse server but server getting 100 request, this slows things down and your users get timeout error or even socket error which means users cannot connect to parse server. This is similar to Ddos attacks. But users doesnt want to take the server down. They want to connect. But connection also consume some system resource. And Parse server was also cpu hungry remember(see number 1). You have to scale parse server(horizontaly or vertically). For 100 request per second 5 parse server would do job. But previously said this numbers depends on your code. You have to test it to find the correct number.
Like I said, these are my observations. If you have a different experience, please tell me so I can fix my error and learn something new.
Parse Server is creating some indices if they donât exist to ensure common operations are index scans, for example the _User.username field. You can find more on that in the Parse Server Storage Adapters source code.
Principally yes, I would say equally with how data is structured, e.g. how many collections need to be touched for a read / write operation.
The optimal data structure depends on the use case, therefore there are many articles to come across in an online search regarding aspects to consider when structuring data in a NoSQL database. In fact, MongoDB provides articles about data model design and schema design to start with.
