For environments running on Cloud Next technologies, application layer utilization metrics have been converted to Cloud Capacity Units. All other metrics have been removed, but may be replaced at a later date.
Your application-layer infrastructure is responsible for processing the code for your application, including calls to the file system and database layers, and calls to external services your application may use to process data or add content to your websites.
Application metrics
Graph | Description |
|---|---|
Total number of requests made to Apache | |
CPU usage for each of the environment’s web infrastructure, as a
percentage of the total available | |
Memory usage for each of the environment’s web infrastructure, as a percentage of the total available | |
Memory usage by cron for each of the environment’s web infrastructure, in MB | |
Number of PHP processes in use for the website | |
This warning is generated by PHP, and indicates that a request came in which PHP could not immediately handle. |
Troubleshooting
Use the information in this section to help you troubleshoot application-related issues with your Cloud Platform application.
Requests count
Requests count indicates how many requests have bypassed Varnish® and hit Apache on your infrastructure, which could be for media files, theme files, or pages generated by your application. This data is useful primarily as context for when sudden changes are seen in other metrics. For example, if a spike in CPU, memory, or PHP processes is indicated but there is no associated spike in this metric, something other than traffic may be causing that behavior.
CPU and memory usage
These metrics can be used to determine how close to capacity your web-tier infrastructure is, and they are often impacted by traffic levels, cron activity, and calls to third-party services associated with cron jobs and web requests.
If the CPU or memory spikes are associated with traffic, increasing your application’s caching settings (which includes implementing or optimizing Memcache utilization) can significantly reduce CPU and memory consumption.
CPU or memory spikes may also be associated with frequent or resource-intensive cron jobs. Reducing the frequency or complexity of cron tasks can immediately reduce CPU and memory consumption.
Utilize an Application Performance Monitoring service (such as New Relic) to identify if the spikes in CPU or memory are associated with specific calls on your website. Optimizing the performance of specific pages can often reduce application CPU and memory utilization, especially if those pages are popular destinations for your end users. As an alternative, if external calls are utilizing all of your CPU or memory, create a Support ticket for assistance.
If it is determined that additional CPU or memory are required for your applications to remain performant, manually increase your infrastructure’s resource capacity or create a Support ticket to determine what options are available.
Cron memory usage in MB
This graph displays the amount of memory that is utilized by cron processes on your infrastructure at any given point in time. Spikes in memory utilization generally indicate when cron jobs are actively running. In general, cron jobs always run on the infrastructure with the lowest number in its name. Spikes in cron memory utilization can lead to spikes in the CPU or memory utilization of your infrastructure, especially when too many jobs are run concurrently, in rapid succession, or if the cron task is expected to complete too much work in a single job. If you notice that cron jobs are causing memory or CPU exhaustion on your infrastructure, attempt to reduce the amount of work assigned to that task, or consider modifying the frequency to minimize the impact of these tasks on the health of your application-tier infrastructure. Some Cloud Platform customers have access to dedicated infrastructure which have been reserved for cron-related activity. In this configuration, the health of the infrastructure does not impact web-related activity. However, if there are insufficient resources on the infrastructure to complete the cron jobs associated with your applications, the tasks may fail to run or finish properly.
PHP process count
PHP processes are the individual workers assigned to serve each page request
which hits your web tier. Every process uses as much CPU as is needed to
complete a page request, plus a portion of your infrastructure’s memory, up to
the limit set by default on your infrastructure (often 128 MB) or set by code
in your application’s settings.php file. This graph displays both the total
number of PHP processes in your web tier infrastructure and the number of PHP
processes used by the specific environment. On infrastructure with only one
active environment, Cloud Platform will display only the total value. This data
can be useful in conjunction with the “Maximum PHP processes reached” errors, the CPU usage, and the Memory usage graphs. If the
“Maximum PHP processes reached” errors graph displays elevated warnings
rates, but you are not near 100% memory utilization, your web-tier
infrastructure or their environments may require manual retuning by Acquia
Support. If you are experiencing elevated warning rates and high memory
utilization, your infrastructure has reached capacity and will require either
an upsize or the same previously noted mitigation steps.
“Maximum PHP processes reached” errors
This warning is generated by PHP, and indicates that a request came in which PHP could not immediately handle due to all available PHP processes being busy. When there are a few warnings per minute, performance is generally unaffected, but during high traffic periods, these can build up, causing uncached page requests to load more slowly. To reduce the frequency of these warnings, use the following methods:
Improve page load times using an application performance monitoring tool, such as New Relic
Improve your cache hit ratio
Eliminate slow database queries
Increase the size of your infrastructure to allow for more PHP processes