Guidelines for choosing a server plan

We offer a number of plans for both your application and your database server, and you may be confused as to which plan to choose for both. This document will help you rectify that confusion.

90% of the time, you won't be picking the correct plan for your server from the get go, which is why we have the provision to change plan whenever you desire. This is because you can only see the workload on the servers once you start using your sites.

The best tool to help you analyse the workload on the server is the Analytics tab on your Frappe Cloud Servers dashboard. You'll see many charts. I'll try to go over some of the important ones that you have quick control over with plans.

Server Analytics

CPU

This is a graph of the CPU Time consumed by the processes on your server.

Idle means there are no processes consuming CPU on the machine. This will go down as CPU is being used i.e there are requests hitting your sites or when background jobs run in your site.

iowait means there are processes waiting for disk operations to finish on your server. This may be reading/writing a big file or loading a table from the database into memory.

For database server, servers spike in iowait is generally a sign to upgrade for more memory . This is because it's best practice to give Mariadb as much memory as possible so the database can mostly reside in RAM. This'll make all the database operations fast as memory is faster than disk.

Load Average

If you're not familiar with load average concept in Linux, refer https://www.digitalocean.com/community/tutorials/load-average-in-linux to learn a bit about it.

In the above chart Load Average 1 is the load average in a time frame of 1 minute, Load Average 5 is the load average in a time frame of 5 minutes and so on.

Spike in Load Average 1 may be harmless and normal but a spike in Load Average 15 might be an issue

If load average comes to more than no. of cpu cores, it may be an indication to optimise your code or upgrade server for more cpu.

Bench Memory Usage

Benches you create on the server will use around 400 MB (appx.) of memory at minimum number of sites (2 gunicorn workers and 1 set of background workers). The system will try to allocate as much free memory that is available to existing bench on the basis of sites on the bench. This means that you should be careful adding too many bench to a server that has only 4 GB total RAM available. You can watch free memory available on the server from the Analytics tab on the server dashboard.

Gunicorn workers

These are processes that serve the web requests to your site. Only 2 workers is enough for a bench with small sites who don't get a lot of concurrent requests. This is because most web requests happen within a span of milliseconds. If you run into a gateway timeout , it is because the web workers are busy executing some long request.

Background workers

These are processes that execute the background jobs in your site. These can be scheduled jobs or jobs created with frappe.enqueue. Long-running jobs/queries/reports should be run here so that you can use your site freely. Even 1 of this worker is enough, as these jobs aren't expected to run instantaneously and go in a queue if the worker is busy.

FAQ

Very High Database Server Memory Usage

MariaDB on all servers is configured to use as much memory as possible. This ensures that almost all db operations are done in memory and hence fast. So it's normal to see 90% or higher memory usage on your database server. read more

We also try to limit the maximum memory mariadb uses in order to avoid a OOM situation and hence downtime.

Work-horse terminated unexpectedly

If your background jobs fail with this particular error, it indicates not enough memory on your application server. You should upgrade the same in such cases.

Why separate Database and Application servers

This is because both database and application servers run different kind of software. And as they do, it is better to keep them on separate VMs as we can configure the VM to be better suited for running the software. For example, database servers tend to be machines with more memory and less cpu as keeping data in memory makes the site run faster. And we can scale the same as the database size increases.