Metrics
Metrics is currently in beta and may be subject to change. We welcome your feedback.
Real-time metrics offer insights into your application's behaviour and performance across different environments. Each application environment displays its metrics separately.
In staging environments, only one instance per type (such as web or worker) exists. In the live environment, the number of instances varies based on the subscription. When there are multiple instances, the displayed metrics represent the cumulative values of each individual instance. Dividing the metric value by the number of instances provides a reliable estimate. However, there may be situations where a single container consumes resources disproportionately due to specific processes. In such cases, although the overall resource usage may seem normal, the overloaded container could potentially trigger errors within the application.
You can select the charts' period and zoom in for more detail by dragging over a particular section.
Memory metrics
The displayed value is the sum of the max memory usage of each container of the given type (e.g. web, worker). The maximum RAM and CPU available, as well as the number of instances running in the live environment, can be tuned in the application subscription.
An application with 2 instances of 2GB each has a total of 4GB RAM allocated to it. A bar in the memory usage chart that reaches 1.8GB for such an application would typically indicate that each instance is using around 900MB.
In the example, when the application surpasses 2GB per instance, it goes beyond its allocated RAM capacity. To handle this, we utilize SWAP, a mechanism that moves excess data to the hard drive. However, since accessing data from the hard drive is much slower than from RAM, this can lead to decreased performance, especially during heavy swapping activity.
If an instance consistently exceeds its allocated RAM, your website may become slow, encounter errors, or crash. We provide SLAs to monitor and address these issues, helping to minimize unnecessary downtime.
It is normal for memory consumption to increase slowly over time after a deployment, as Unix-based systems will use available memory for maximum benefit. However, steadily climbing figures that do not plateau can also be a sign of a memory leak.
CPU metrics
The displayed value is the sum of the average CPU usage of each container of the given type (e.g. web, worker). Figures for CPU reflect the total number of instances available to the environment.
Given a website with 3 web instances, if the average CPU usage for 1 is 0.2%, for 2 is 2.0% and for 3 is 8.0%, the value shown will be 0.2+2.0+8.0 > 10.2%. The exact same value, 10.2%, will be shown if all containers used an average of 3.4%.
As CPU usage for an instance approaches its maximum there will be a small performance loss; after that, there will be a dramatic decline in performance, and issues such as dropped connections and requests that don't get answered because there are not enough resources available to answer them.
We provide SLAs to monitor and address these issues, helping to minimize unnecessary downtime.