Cloud Platform
Stack Metrics - Load balancing
Your load balancers are responsible for handling requests from either visitors to your application or from your content delivery network (CDN). Such an infrastructure uses Nginx to route HTTP requests to Varnish®, which determines if it has a cached version of your application’s content. Any requests that can’t be served from Varnish cache will be routed round-robin to infrastructure in your web tier.
| Graph | Description |
|---|---|
| Requests count | Total number of requests made to Nginx and Varnish. |
| HTTP responses | HTTP response codes, grouped by status range (2xx, 3xx, 4xx, 5xx). |
| Varnish cache hit rate | Varnish cache hit rate as a percentage of total requests. |
| CPU and memory usage | CPU usage and memory usage for each of the environment’s load balancers, as a percentage of the total available. |
Use the information in this section to help you troubleshoot load balancer-related issues with your Cloud Platform application.
Depending on an application’s HTTPS traffic and Varnish configuration, requests can hit Varnish, Nginx, or both. Although HTTPS requests pass through Nginx before reaching Varnish, HTTP requests bypass Nginx entirely.
Request data can be used to obtain a basic sense of traffic patterns. For more exact metrics regarding traffic to your websites, we recommend that you use a third-party service. This data is useful for tracking general traffic patterns and identifying either spikes in traffic (which can be associated with promotional events or an attack), or sudden drops in traffic (which can be associated with issues in your network such as DNS, the CDN, or the load balancers).
For more information about Varnish, see Using Varnish.
The following numbers indicate the success or failure rate of content requests to the load balancer tier of your stack:
page not found.As a general rule, an optimized website will have few 3xx or 4xx responses, and should have no 5xx response codes.
For applications with load balancers shared with other applications, it is important to note that the response codes are recorded at the infrastructure level. Due to this behavior, other applications using the same load balancers may be to blame.
This number indicates what percentage of requests to your load balancers are being served from Varnish. Depending on the needs of your websites, this number may range from a small value (for websites with mostly authenticated traffic or no caching) to almost 100% (for websites with no authenticated traffic and long durations set for their external caching values). Since HTTPS requests first pass through Nginx before reaching Varnish, applications with a high percentage of HTTPS requests will see the Varnish cache rate be lower than the request rate.
A resilient application will have a cache hit rate of 80% or greater, while a rate greater than 95% is considered to be exceptionally resilient to spikes in traffic. It is normal for an application’s cache hit rate to fluctuate throughout the day. During off-peak hours, applications will generally serve fresh content as caches from peak hours begin to expire, and requests for popular pages happen less frequently. To reduce the amount of traffic hitting your other infrastructure, attempt to increase your website’s cache hit rate to the highest possible value.
Load balancers are generally resilient, able to serve hundreds or thousands of requests per minute without any measurable increase in CPU or memory usage. However, spikes in traffic, sustained high traffic, or large cached media files can all result in load balancers running out of CPU or memory. Although high CPU usage will usually have a minor impact on website performance, running out of memory can lead to infrastructure impairment and should be avoided. Although Acquia monitors for impaired infrastructure, an infrastructure can continue serving traffic indefinitely even when CPU or memory are at or near capacity. If you notice that your load balancers are routinely hitting CPU or memory capacity, create a Support ticket to determine what options are available to increase your load balancer capacity.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
| Requests count |
| Total number of requests made to Nginx and Varnish. |
| HTTP responses | HTTP response codes, grouped by status range (2xx, 3xx, 4xx, 5xx). |
| Varnish cache hit rate | Varnish cache hit rate as a percentage of total requests. |
| CPU and memory usage | CPU usage and memory usage for each of the environment’s load balancers, as a percentage of the total available. |
Use the information in this section to help you troubleshoot load balancer-related issues with your Cloud Platform application.
Depending on an application’s HTTPS traffic and Varnish configuration, requests can hit Varnish, Nginx, or both. Although HTTPS requests pass through Nginx before reaching Varnish, HTTP requests bypass Nginx entirely.
Request data can be used to obtain a basic sense of traffic patterns. For more exact metrics regarding traffic to your websites, we recommend that you use a third-party service. This data is useful for tracking general traffic patterns and identifying either spikes in traffic (which can be associated with promotional events or an attack), or sudden drops in traffic (which can be associated with issues in your network such as DNS, the CDN, or the load balancers).
For more information about Varnish, see Using Varnish.
The following numbers indicate the success or failure rate of content requests to the load balancer tier of your stack:
Cloud Platformpage not found.As a general rule, an optimized website will have few 3xx or 4xx responses, and should have no 5xx response codes.
For applications with load balancers shared with other applications, it is important to note that the response codes are recorded at the infrastructure level. Due to this behavior, other applications using the same load balancers may be to blame.
This number indicates what percentage of requests to your load balancers are being served from Varnish. Depending on the needs of your websites, this number may range from a small value (for websites with mostly authenticated traffic or no caching) to almost 100% (for websites with no authenticated traffic and long durations set for their external caching values). Since HTTPS requests first pass through Nginx before reaching Varnish, applications with a high percentage of HTTPS requests will see the Varnish cache rate be lower than the request rate.
A resilient application will have a cache hit rate of 80% or greater, while a rate greater than 95% is considered to be exceptionally resilient to spikes in traffic. It is normal for an application’s cache hit rate to fluctuate throughout the day. During off-peak hours, applications will generally serve fresh content as caches from peak hours begin to expire, and requests for popular pages happen less frequently. To reduce the amount of traffic hitting your other infrastructure, attempt to increase your website’s cache hit rate to the highest possible value.
Load balancers are generally resilient, able to serve hundreds or thousands of requests per minute without any measurable increase in CPU or memory usage. However, spikes in traffic, sustained high traffic, or large cached media files can all result in load balancers running out of CPU or memory. Although high CPU usage will usually have a minor impact on website performance, running out of memory can lead to infrastructure impairment and should be avoided. Although Acquia monitors for impaired infrastructure, an infrastructure can continue serving traffic indefinitely even when CPU or memory are at or near capacity. If you notice that your load balancers are routinely hitting CPU or memory capacity, create a Support ticket to determine what options are available to increase your load balancer capacity.
If this content did not answer your questions, try searching or contacting our support team for further assistance.