The current formula utilized for these calculations is:
Additional formulas will be added over time as new technologies are added to the Acquia Cloud Platform.
For subscribers with server-based subscriptions, Cloud Capacity Units are informational only, unless your environments have been upgraded to Acquia Cloud Next, which is powered by serverless technologies. Subscriptions which exceed the total Cloud Capacity Unit equivalent of contracted infrastructure capacity may be subject to additional fees if the elevated utilization recurs or persists.
For subscribers with subscriptions that leverage Acquia’s Views and Visits model, Cloud Capacity Units are a component of Resource Limits. Subscriptions that exceed the Resource Limits guidelines associated with your contracted Views and Visits capacity may be subject to additional fees if the elevated utilization recurs or persists.
Once Cloud Capacity Units become the primary resource tracking metric for a subscription, they will provide a number of benefits to Cloud Platform subscribers.
At this time, CCUs do not include storage utilization, which is tracked separately on the Acquia Cloud Platform.
At this time, CCUs will only be used for diagnostic purposes for subscribers on these pricing models.
Since CCUs can serve as an indicator of an application’s health or performance, you should attempt to correlate unexpected spikes or drops in Cloud Capacity Units with development activities such as code changes, site configuration changes, and environment configuration changes, or with changes in traffic. While modest spikes in CCUs should be expected during mid-day traffic peaks or whenever cron runs, unexpected spikes that jump too high and occur too often could be indicative of a caching or configuration problem that could lead to a temporary resource limit being imposed on your environment by Acquia. In the unlikely event that this happens, contact Acquia Support for assistance.
To ensure that emails are sent through Platform Email, you must update your
settings.php file. For more information, see Acquia require line.
Platform Email supports the following flags for the Sendmail command:
f, i, r, s, t, F
Note that Platform Email does not support bs.
On Wednesday, 24 March 2021, Acquia will begin upgrading customer applications to Acquia Cloud Next. Acquia Cloud Next technologies provide better performance, scalability, and resiliency during high load. Powered by advanced serverless architecture, Acquia Cloud Next ensures applications can scale faster to satisfy the demands of high traffic events and resource intensive processes.
For more information on Acquia Cloud Next and to learn how it differs from Acquia Cloud Classic, see Acquia Cloud Next.
Acquia Cloud Next is powered by Kubernetes-managed clusters and advanced file system and database management technologies that leverage pooled resources across hundreds of containerized and virtually isolated environments. This architecture allows non-production environments to run in a high-availability configuration by default. Also, it allows production environments to leverage the full capacity of an entire regional cluster, if necessary, to respond to spikes in traffic or other forms of high resource utilization.
On Acquia Cloud Next, non-production environments are permitted to scale up to a predefined point before additional resources stop getting allocated. Acquia Support can raise this limit on a case-by-case basis for customers who haven’t exceeded their Resource Limits or contractual Cloud Capacity Unit thresholds.
Production environments are also permitted to scale up to a predefined point above the expected amount of cloud capacity, required to satisfy the level of traffic, associated with a given subscription. However, in the unlikely event that any Production environment nears that threshold, Acquia Support will step in to audit the activity on your account and determine if additional auto-scaling can be permitted or if some form of intervention is required to reduce utilization back to normal levels. For example, if your site is under attack or inadvertently consumes more resources than expected.
Once a spike in resource utilization subsides, all environments on Acquia Cloud Next automatically reduce the amount of dedicated capacity to make it available to the regional pool once more.
The dynamic auto-scaling functionality in Acquia Cloud Next provides flexibility and almost limitless growth when extra cloud capacity is required.
For customers on Acquia’s Views/Visits pricing model, Acquia reaches out only if:
In either case, overage fees will be assessed starting from the date of initial notification by Acquia.
For customers on Acquia’s legacy infrastructure-based pricing model, Acquia doesn’t notify you about transient Cloud Capacity Unit spikes that exceed your contractual capacity limits. Such spikes must be rare and shouldn’t exceed three hours in duration. However, recurring or excessive spikes in resource utilization above your contractual capacity limits may result in:
In either case, overage fees will be assessed starting from the date of initial notification by Acquia. However, fees may be waived in the event of a subscription upgrade.
Environments running on Acquia Cloud Next dynamically scale to meet active demand. Hence, they can’t be scaled manually, even upon request. Acquia will provide the ability to limit scaling per-environment in a later release.
Acquia Cloud Next leverages pooled capacity to ensure every production environment can utilize as much capacity as it needs and when it needs it. It was also designed with security and compliance in mind, and leverages an architecture that virtually eliminates the need for permanently dedicated capacity to properly protect an environment.
Hence, Acquia Cloud Next is currently only available in a pooled configuration. More information about dedicated capacity configurations will be available later this year.
As an Acquia Cloud Platform customer, you are always advised to contact Acquia Support before any high traffic event occurs. This information ensures that Acquia’s on-call teams know about the possibility of a spike in legitimate traffic on an environment. This also gives Acquia the context needed to provide assistance, if required.
Environments running on the Acquia Cloud Next technologies don’t require proactive capacity increases as such environments dynamically scale as needed. However, Acquia teams may adjust some settings in anticipation of increased traffic to ensure optimal performance throughout the event.
At this time, Acquia can neither provide build scripts and images for the Acquia Cloud Next containers nor run container images and build scripts provided by customers. To get this functionality added to the Acquia Cloud Platform roadmap, contact your Acquia account team.
On the Acquia Cloud Classic infrastructure, code deployments involves a multi-step process:
[git pull] operation to pull the new code
to a hidden repository folder.This process, while typically fast, can result in inconsistent code deployments across multiple web nodes.
In contrast, modern deployment methodologies advocate for atomic updates, a concept Acquia has implemented Acquia Cloud Next with the following sequence:
post-code-deploy Cloud Hooks are triggered.This process not only allows for clean and consistent updates to your environment but also ensures that your environments constantly run on fresh and healthy pods.
On the Acquia Cloud Classic infrastructure, Memcached was typically configured to run across all available web nodes with 64 MB of memory allocated to each infrastructure. This isolated a relatively small amount of system memory, pulling it away from PHP, cron, and other application-layer services for the exclusive use of Memcached.
Some customers on the Acquia Cloud Classic infrastructure also invested in dedicated Memcache capacity, where some infrastructure was set aside for the exclusive use of Memcached so that two or more nodes could allocate nearly all of their available memory to Memcache. This configuration was typically only available to top-tier accounts and for production environments.
On Acquia Cloud Next, Memcached is rearchitected to run in a high-availability configuration on both production and non-production environments. This not only results in improved performance on non-production environments but also expands access to a more performant Memcached configuration to all customers by default.
For environments running on Acquia Cloud Next, Drupal pods connect to Memcached
pods through a relay point running mcrouter for improved performance and resiliency. Owing to this optimization, the
[mcstat] command won’t function during SSH sessions and the Memcache module. After
using SSH to access an environment, use acquia-memcache stats to access
Memcached data.
The Acquia Cloud Platform team is actively researching potential mid-term solutions to both limitations to improve customer visibility into the health and performance of Memcached on your environments.
On Acquia’s Cloud Classic infrastructure, you have access to the
/var/log/sites directory to view environment log data and store custom
logs. On average, these logs remain available for weeks or months at a time,
but would be lost whenever infrastructure was relaunched during maintenance
events, sometimes limiting the historical data available.
Since Acquia Cloud Next leverages ephemeral containers and pods, the same
methodology is not available for upgraded environments. Hence, you must
configure your custom logs to be stored in an alternative location:
/shared/logs. Hence, you must access historical logs for your environments
using an alternative method such as Acquia CLI.
For this reason, Acquia has updated the Download Logs functionality in the Acquia Cloud Platform user interface and Cloud API v2. Prior to this update, you could only download logs for the current day. However, with this update, you can select a day or time period over the past 30 days. You can download logs up to 24 hours. This enhancement not only makes log access easier but also ensures that your logs persist even after maintenance events.
On the Acquia Cloud Classic infrastructure, cron jobs, SSH, and Cloud Hooks run
on the same infrastructure. Hence, they might compete with other processes,
such as PHP or MySQL for system resources. You can also ssh directly to a
specific web node and purchase dedicated cron capacity to ensure that a
single node was always available and isolated for the sole use of frequent or
resource-intensive cron processes.
On Acquia Cloud Next, the existing Acquia Cloud Classic functionality is enhanced. By default, all production and non-production environments have access to isolated cron, SSH, and Cloud Hooks pods that run only when needed and shut down whenever they are not. Thus, your environments are more efficient by default and utilize fewer Cloud Capacity Units when idle because excess pods aren’t left running. Additionally, cron, SSH, and Cloud Hook activity can’t interfere with Drupal, Memcached, or MySQL activity by competing for resources.
On Acquia Cloud Next, long running or stuck processes, such as processes running cron or Cloud Hooks, can’t be terminated manually. Contact Acquia Support for assistance if this happens in one of your environments.
Environments upgraded to Acquia Cloud Next may require adjustments to scripts, cron jobs, and other automations due to the updated location of several file directories. For more information, see Working with files.
53 State Street, 10th Floor
Boston, MA 02109
United States
Phone: 888-922-7842