The Infrastructure page is available only for Cloud Next environments with Elastic IP addresses (EIPs) information. If EIPs are not provisioned for your environment, the system does not display this page.
Acquia’s mission is to provide subscribers with access to the best Drupal hosting platform in the world, while also recognizing the need to allow reasonable levels of customization. Acquia’s infrastructure tuning formulas provide a balance of stability, performance, and customization.
To understand infrastructure tuning, it is important to understand these key concepts:
PHP process - A PHP process is used whenever a page request reaches a web infrastructure. One PHP process is required for each page request.
Memcache - A system used to store Drupal’s cache tables in infrastructure memory, rather than on the hard drive. This is sometimes more performant than contacting MySQL for all data necessary to process a request.
Opcode cache - A PHP caching layer, OPcache, which speeds up code execution time by caching compiled PHP logic.
PHP memory - Memory reserved for a PHP process to store variables and use when computing.
For applications and environments running on an infrastructure with web, file system, and database operations sharing resources, Acquia tunes your infrastructure by default to allocate half of all available memory to the database and 200 MB of additional memory for the operating system. The remaining memory can be allocated among Memcache, opcode caching, and PHP.
For some Cloud Classic production environments on Cloud Platform Enterprise and Site Factory, as well as all environments on Cloud Next, dedicated resources are always assigned directly to each service to prevent resource contention: Drupal (Apache/PHP), Memcache, SSH, cron jobs, cloud hooks, file system, and database.
Applications and PHP processes
Cloud Platform infrastructure leverages Amazon’s EC2 infrastructure. The processing power of EC2 infrastructure is measured in units called Elastic Computing Units (ECUs) or Virtual Compute Units (vCPUs). As a general rule, it is best to run no more PHP processes per application on a Cloud Platform Professional infrastructure than three times the ECU of the infrastructure.
By default, Cloud Platform Professional systems provision each application with three environments: Development, Staging, and Production. This means an infrastructure running three applications must support nine total environments. While these environments will share some resources, like CPU and MySQL memory, as needed, other resources like PHP processes have per-environment and per-infrastructure limits which help ensure overall hosting stability. These limits cannot be modified to allocate more or fewer processes to a single environment.
Note
PHP process limits will be reduced infrastructure-wide if more environments are added to your Cloud Classic infrastructure, or if any memory limits (PHP, opcode cache, Memcache) are increased beyond their default values. As a result, we strongly recommend that subscribers carefully consider the impact of these changes to existing applications before making them.
When you are deciding how big an infrastructure you need to purchase on Cloud Platform Professional,, it is important to make sure that you will have at least one available PHP process per application. The more PHP processes an application is allocated, the greater the number of simultaneous Page Views your infrastructure can handle. When your infrastructure doesn’t have an available PHP process for a page request, Cloud Platform displays a 503 “Service Unavailable” error message to the visitor. On an Acquia-hosted application, the 503 error message appears similar to the following:
When a Drupal application receives a page request, but there are no PHP processes available or able to be spawned to handle it immediately, the application may throw a “Max children reached” warning and waits for a process to become available. After a while, the application stops waiting to handle any such requests and the request fails with a “Temporarily Unavailable” message.
If your application returns frequent HTTP 503 status codes caused by long PHP queue wait times, you have two primary options for increasing the number of available PHP processes:
Optimize the code running the application
Purchase more infrastructure capacity
While purchasing more infrastructure is an immediate solution, there are circumstances where inefficiencies in the application code prevent additional infrastructure from yielding benefits. It is always a good idea to attempt to optimize an application, even if you wind up purchasing more cloud capacity. For more information about optimizing your applications, see Improving application performance.
Tuning your infrastructure configuration
Important
The Infrastructure page is available only for Cloud Next environments with Elastic IP addresses (EIPs) information. If EIPs are not provisioned for your environment, the system does not display this page.
Acquia’s mission is to provide subscribers with access to the best Drupal hosting platform in the world, while also recognizing the need to allow reasonable levels of customization. Acquia’s infrastructure tuning formulas provide a balance of stability, performance, and customization.
To understand infrastructure tuning, it is important to understand these key concepts:
PHP process - A PHP process is used whenever a page request reaches a web infrastructure. One PHP process is required for each page request.
Memcache - A system used to store Drupal’s cache tables in infrastructure memory, rather than on the hard drive. This is sometimes more performant than contacting MySQL for all data necessary to process a request.
Opcode cache - A PHP caching layer, OPcache, which speeds up code execution time by caching compiled PHP logic.
PHP memory - Memory reserved for a PHP process to store variables and use when computing.
For applications and environments running on an infrastructure with web, file system, and database operations sharing resources, Acquia tunes your infrastructure by default to allocate half of all available memory to the database and 200 MB of additional memory for the operating system. The remaining memory can be allocated among Memcache, opcode caching, and PHP.
For some Cloud Classic production environments on Cloud Platform Enterprise and Site Factory, as well as all environments on Cloud Next, dedicated resources are always assigned directly to each service to prevent resource contention: Drupal (Apache/PHP), Memcache, SSH, cron jobs, cloud hooks, file system, and database.
Applications and PHP processes
Cloud Platform infrastructure leverages Amazon’s EC2 infrastructure. The processing power of EC2 infrastructure is measured in units called Elastic Computing Units (ECUs) or Virtual Compute Units (vCPUs). As a general rule, it is best to run no more PHP processes per application on a Cloud Platform Professional infrastructure than three times the ECU of the infrastructure.
By default, Cloud Platform Professional systems provision each application with three environments: Development, Staging, and Production. This means an infrastructure running three applications must support nine total environments. While these environments will share some resources, like CPU and MySQL memory, as needed, other resources like PHP processes have per-environment and per-infrastructure limits which help ensure overall hosting stability. These limits cannot be modified to allocate more or fewer processes to a single environment.
Note
PHP process limits will be reduced infrastructure-wide if more environments are added to your Cloud Classic infrastructure, or if any memory limits (PHP, opcode cache, Memcache) are increased beyond their default values. As a result, we strongly recommend that subscribers carefully consider the impact of these changes to existing applications before making them.
When you are deciding how big an infrastructure you need to purchase on Cloud Platform Professional,, it is important to make sure that you will have at least one available PHP process per application. The more PHP processes an application is allocated, the greater the number of simultaneous Page Views your infrastructure can handle. When your infrastructure doesn’t have an available PHP process for a page request, Cloud Platform displays a 503 “Service Unavailable” error message to the visitor. On an Acquia-hosted application, the 503 error message appears similar to the following:
When a Drupal application receives a page request, but there are no PHP processes available or able to be spawned to handle it immediately, the application may throw a “Max children reached” warning and waits for a process to become available. After a while, the application stops waiting to handle any such requests and the request fails with a “Temporarily Unavailable” message.
If your application returns frequent HTTP 503 status codes caused by long PHP queue wait times, you have two primary options for increasing the number of available PHP processes:
Optimize the code running the application
Purchase more infrastructure capacity
While purchasing more infrastructure is an immediate solution, there are circumstances where inefficiencies in the application code prevent additional infrastructure from yielding benefits. It is always a good idea to attempt to optimize an application, even if you wind up purchasing more cloud capacity. For more information about optimizing your applications, see Improving application performance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform