Platform CDN is available only for eligible Acquia Cloud Enterprise accounts.
Using Platform CDN, you can deliver accelerated digital experiences to global audiences by caching pages and static assets, including JavaScript, CSS, and images, at over 65 points of presence (POPs) around the world. Visitors accessing your website load the static assets from the POP closest to their location, which decreases the time required to load a page and increases conversions.
Based on years of experience accelerating Drupal applications through Varnish®, Acquia has configured Platform CDN to optimize the delivery of digital experiences.
Before you enable and provision Platform CDN
Prerequisites
Ensure that the Platform CDN entitlement is added to your Acquia subscription.
Have at least one custom domain, preferably with a valid SSL/TLS root certificate.
Get an understanding of your site’s caching strategy.
Important
If you are using SSL/TLS, you must have a valid RSA 2048-bit signed certificate uploaded to Cloud Platform to use the certificate with Platform CDN. Self-signed and other certificates are not supported with Platform CDN. If you own a wildcard certificate, upload the certificate to all relevant environments, including the RA environment with Remote Administration. If you are unsure of your certificate’s size, run the following command in a terminal window:
By default, HIPAA and PCI compliance are always on for all cached objects with Platform CDN. It is up to your team to configure objects that do not require this compliance.
If your objects are not HIPAA or PCI compliant and you want the cache lifetime longer than 24 hours, you must add the header X-Acquia-CDN-HP-Off. This indicates that the object is not compliant and can be stored in cache or on disk at the CDN. HIPAA and PCI sensitive objects are not stored on disk at the CDN by default.
Note
Session objects, such as objects with session cookies, are not stored in cache.
In the left navigation pane, click Domain Management.
On the right, click the CDN tab.
Important
You can use Platform CDN only with custom domains.
This tab is visible to only Acquia customers who has the Platform CDN entitlement added to their subscriptions.
Click Provision to provision a CDN for your environment. Acquia provisions all of the custom domains in your environment on CDN. Acquia only provisions Platform CDN for custom domains. Acquia default domains does not function on CDN. For any non-conforming domain patterns, the system displays
Note
After adding Platform CDN to your environment, Cloud Platform automatically keeps CDN configuration up-to-date. For example, when you add or remove a domain, or update an SSL certificate, you may see a CDN provisioning or updating task in the task log view. You may also see a CDN provisioning or updating task after you deploy code to an environment due to the internal operations of the system.
Testing Platform CDN
To test Platform CDN, use one of the following methods:
To test through the /etc/hosts file method:
Edit your /etc/hosts file to add a line based on the following format by using the IP address and your domain name:
Do not use the Chrome browser as it does not read the /etc/hosts file.
Some browsers require configuration to read DNS from the /etc/hosts file.
Enter the domain name in your browser and examine the page response headers.
To test through the curl command method, run the following command by using the IP address and your domain name:
curl -Is -X GET https://www.example.com --resolve www.example.com:443:151.101.1.193
Disabling Platform CDN
Important
Ensure that you point DNS to your Cloud Platform balancers before you disable CDN. This ensures that your sites remain accessible even after CDN is disabled.
In the left-hand navigation bar, click Domain Management.
On the right, click CDN.
To disable CDN for the entire environment, click Disable CDN.
Disabling Platform CDN for a single or select group of domains
To disable Platform CDN for a single or select group of custom domains, visit your DNS provider and point DNS for the chosen domain(s) to your Acquia load balancer EIP. This information is available in the Regional Origin sub-section of DNS information.
Note
As you provision Platform CDN, all your custom domains are pushed to the CDN. Domains added or removed from the Cloud Platform user interface are added or removed from CDN and remain in sync. You control which domains actually use CDN by setting each domain’s DNS records accordingly.
SSL certificates and Platform CDN
Cloud Platform supports SSL certificates on both Platform CDN and Cloud Platform balancers, enabling you to deliver fully secure experiences for your visitors. Cloud Platform automatically copies certificates to Platform CDN as part of the provisioning process. Ensure that your certificate is uploaded to Cloud Platform. Any certificates uploaded after the initial provisioning of Platform CDN are also automatically uploaded to Platform CDN.
Note
Ensure that your certificates use a 2048-bit private key before enabling Platform CDN. You can only use the certificates that are created with a 2048-bit private key.
Understanding cache invalidation
Cache invalidation is a method of displaying new content to connected clients. During invalidation, objects are marked as outdated, and the next time a client requests these objects, the client is delivered a new version. Acquia offers two approaches to cache invalidation on its Varnish-based load balancers and Platform CDN layers: Purge and Ban.
Purge requests
Purge immediately removes content from Varnish. When the client requests the data again, the request bypasses Varnish and Drupal responds to the request. This is a path-based approach. This is the primary approach for customers using Drupal 7 and the Acquia Purge module.
Ban requests
Ban adds cached object references to a list, and client requests are checked against this list to see if there are any matches. If so, new content is fetched from the application, returned to the client, and added to the cache. Cached content is updated after a client requests the information, unlike the Purge method. This is the primary approach for customers using Drupal 9 with Purge and Acquia Purge modules.
Configuring your Drupal site for cache invalidation
Follow the next steps based on your Drupal version:
Drupal 9 utilizes Drupal’s Cache API and the Purge module, both of which were architected with cache invalidation in mind. This method utilizes cache tags. Cache tags can be added to any piece of content in Drupal. With the presence of cache tags, the Purge module is able add these cache tags to a Ban list. This casts a wider net, allowing Acquia’s customers to implement a comprehensive cache invalidation strategy that caches objects for longer periods of time (TTL). When editors make content changes, it appears fresh when requested immediately.
Platform CDN respects Cache-Control and Surrogate-Control HTTP headers and tag-based invalidation. Acquia recommends using both methods as part of your application’s caching strategy.
Drupal 9 HTTP headers
Coupled with the Purge and Acquia Purge modules, the Drupal 9 cache invalidation framework expires content at Acquia Varnish and Platform CDN whenever changes occur to tagged content. This feature means that cache lifetimes at both Acquia Varnish and Platform CDN can be set to very long times and even months.
For information about how the Drupal application sets cache headers, see:
Drupal 7 does not natively support tag-based invalidation. Therefore, Acquia recommends setting Drupal’s maximum time for keeping cached assets to 60 minutes. This allows assets to remain cached for a moderate amount of time before updates are fetched from Drupal. This value can be configured downwards to ensure that your visitors receive the updated content.
To configure the maximum time, log in with administrator privileges and navigate to config/development/performance. Enable caching for anonymous users and set Expiration of cached pages to the duration you require.
These settings generate the following HTTP header:
Cache-Control: public, max-age=3600
Public means the response can be stored by all caches, including Varnish, Platform CDN, and browser caches.
Cache-Control header settings only apply to dynamic content. All static assets, such as CSS fonts, images, and JavaScript files, are given Cache-Control headers by an .htaccess directive and the Apache web infrastructure:
You can leverage Cache-Control and Surrogate-Control HTTP headers and tag-based invalidation in Javascript applications based on Node.JS.
Cache-Control works when you set it up on the server side. When you do not set up this header on the server side, the Age header increases to 3600 seconds. Here, 3600 seconds is the TTL value. For example,
To set up the Cache-Control header on the server (Acquia domain, for example, https://testdev.prod.acquia-sites.com/), run the following command and restart your server:
Note that Platform CDN takes around 30 mins for the changes to come in effect. As per the example, you can verify the changes by accessing the Acquia domain: https://testdev.prod.acquia-sites.com/. This returns the Cache-Control header in the response. After around 30 minutes, you can access the Node.js domain to view the Cache-Control header as well:
Cache clearing occurs automatically due to the Acquia Purge module.
Manually purging caches using Drupal admin
To purge all content from all caches, use Drupal’s Clear All Caches option. This also clears Acquia Varnish cache and Platform CDN cache. If the Acquia Purge module: Platform CDN purger is installed and configured correctly, you must purge all content. To do so, navigate to admin > Configuration > Performance and select the Clear all caches option.
Manually purging all caches or individual objects from Platform CDN
Important
These instructions clear content from Platform CDN only. To replace the older content with new content, purge the content from Acquia Varnish first.
Retrieve the value of service_id and token from Acquia Support.
Purge Platform CDN by running the following curl command with the token in the header and the service_id in the URL path as shown in the following example:
curl -X POST -H "Fastly-Key:<Platform CDN token>" -H "Accept: application/json" https://api.fastly.com/service/<Platform CDN Service ID>/purge_all
Use the token and Service ID values provided to you by Acquia Support.
For example,
curl -X POST -H "Fastly-Key:DMDf1ryoZiERdryIxQAb4seLOBqLfLMU" -H "Accept: application/json" https://api.fastly.com/service/4SsvFsxK25Z7t16kTqzu7d/purge_all
Navigate to your environment and click the Domains Management menu.
On the Domains tab, select Clear all caches for the domain for which you want to clear the cache.
The system clears both Acquia Varnish and Platform CDN caches.
Troubleshooting
Provisioning
If you experience issues provisioning Cloud Platform CDN, review the following likely causes:
There are no custom domains registered to your environment:
The default *.acquia-sites.com domain cannot be added to CDN. You must add at least one of your own domains before Platform CDN can be provisioned.
Your SSL/TLS certificate is not 2048-bit:
Ensure your certificates use a 2048-bit private key before enabling Platform CDN. You can only use the certificates that are created with a 2048-bit private key.
There is an older SSL/TLS certificate being served instead of a newly uploaded certificate:
Platform CDN serves a valid certificate with the closest matching CN or SAN. Deactivate any older certificates through the Cloud Platform user interface to remove them from Platform CDN.
Your domain was previously registered with Acquia’s CDN partner, Fastly Inc.:
If you have previously created a Fastly account using one of your domain names, create a Support ticket. Acquia Support will work with Fastly to transfer the domain for use on Platform CDN.
Performance
HTTP to HTTPS redirect gets stuck in a 301 redirect loop:
Ensure that your application is serving a Cache-Control header with max-age:3 or must-revalidate value. This ensures that the browser does not use its local cache.
Purge token lost or doesn’t work:
Use Drush 9 to run drush p:dia. If that command is not available, use the following method to ensure that all modules are installed and enabled:
# in your local dev environment
git clone [email protected]:manualtest.git
cd manualtest/docroot
# Use composer to install acquia_purge 1.1 beta and its dependencies
composer config minimum-stability 'beta'
composer config prefer-stable true
composer require 'drupal/acquia_purge:1.1-beta1'
# Push the code back and enable the module using drush
git add.
git commit -a -m "Add Acquia Purge module"
git push
ssh {{YOUR SSH URI HERE}}
sudo su
cd /var/www/html/{{YOUR ENVIRONMENT NAME HERE}}/docroot/
source /mnt/users/[SITEGROUP NAME]/dev.shell
drush9 en acquia_purge
yes
#>> [success] Successfully enabled: acquia_purge, purge, purge_drush
# list all the available purgers
drush9 p:purger-lsa
#>> --------------------- ---------------------------- ----------------------------------------------
#>> Plugin Label Description
#>> --------------------- ---------------------------- ----------------------------------------------
#>> acquia_purge Acquia Cloud Invalidate content from Acquia Cloud.
#>> acquia_platform_cdn Acquia Platform CDN (beta) Invalidate content from Acquia Platform CDN.
#>> --------------------- ---------------------------- ----------------------------------------------
# Enable the acquia purge and then the acquia_platform_cdn in that order to ensure
# varnish clears first and then platform_cdn clears after a short delay
drush9 p:purger-add acquia_purge
drush9 p:purger-add acquia_platform_cdn
# Enable the other purge modules that need manually enabled for some reason
drush9 pm:list | grep purge
drush9 en purge_processor_cron
drush9 en purge_processor_lateruntime
drush9 en purge_queuer_coretags
drush9 en purge_tokens
drush9 en purge_ui
drush9 en purge_drush
drush9 pm:list | grep purge
# Run the diagnostic
drush9 p:dia
Platform CDN limits and restrictions
Important
Acquia balancers have limits on request and response URL, header, and cookie sizes.
Item
Limit
Notes
Maximum vary fields
200 / 400
Exceeding the soft limit results in no error. Newer variants displace the oldest.
URL size
8 KB
Exceeding the limit results in a too long request string error.
Cookie size
32 KB
Exceeding the limit results in Fastly stripping the cookie and setting req.http.Fastly-Cookie-Overflow = “1”.
Request header size
69 KB
Depending on the circumstances, exceeding the limit can result in:
Fastly closes the client connection abruptly.
Client receives a 502 Gateway error response with an I/O error in the body.
Client receives a 503 Service Unavailable response with a Header overflow error in the body.
Response header size
69 KB
Exceeding the limit results in a 503 backend read error. See Common 503 errors for more information.
Request header count
96
Exceeding the limit results in a Header overflow error. A small portion of this limit is reserved for internal Fastly use, making the practical limit closer to 85.
Response header count
96
Exceeding the limit results in a Header overflow error. A small portion of this limit is reserved for internal Fastly use, making the practical limit closer to 85.
Surrogate key header size
16 KB
Exceeding the limit results in no error and any keys past the one that exceeds the limit, are dropped. Acquia Purge keys are 4 bytes + 1byte for the space separator, each implying a maximum of over 3000 tags per object.
Unsupported products and features
The following products and features are not supported on Platform CDN:
Acquia recommends that you do not use multiple WAFs or CDNs in front of a site while redirecting requests between those WAFs or CDNs. You can leverage Fastly-powered Platform CDN or any other WAF or CDN, including Edge Security or Edge CDN. However, Acquia does not support the use of multiple different WAFs, CDNs, or both in a layered approach.
Platform CDN is available only for eligible Acquia Cloud Enterprise accounts.
Using Platform CDN, you can deliver accelerated digital experiences to global audiences by caching pages and static assets, including JavaScript, CSS, and images, at over 65 points of presence (POPs) around the world. Visitors accessing your website load the static assets from the POP closest to their location, which decreases the time required to load a page and increases conversions.
Based on years of experience accelerating Drupal applications through Varnish®, Acquia has configured Platform CDN to optimize the delivery of digital experiences.
Before you enable and provision Platform CDN
Prerequisites
Ensure that the Platform CDN entitlement is added to your Acquia subscription.
Have at least one custom domain, preferably with a valid SSL/TLS root certificate.
Get an understanding of your site’s caching strategy.
Important
If you are using SSL/TLS, you must have a valid RSA 2048-bit signed certificate uploaded to Cloud Platform to use the certificate with Platform CDN. Self-signed and other certificates are not supported with Platform CDN. If you own a wildcard certificate, upload the certificate to all relevant environments, including the RA environment with Remote Administration. If you are unsure of your certificate’s size, run the following command in a terminal window:
By default, HIPAA and PCI compliance are always on for all cached objects with Platform CDN. It is up to your team to configure objects that do not require this compliance.
If your objects are not HIPAA or PCI compliant and you want the cache lifetime longer than 24 hours, you must add the header X-Acquia-CDN-HP-Off. This indicates that the object is not compliant and can be stored in cache or on disk at the CDN. HIPAA and PCI sensitive objects are not stored on disk at the CDN by default.
Note
Session objects, such as objects with session cookies, are not stored in cache.
In the left navigation pane, click Domain Management.
On the right, click the CDN tab.
Important
You can use Platform CDN only with custom domains.
This tab is visible to only Acquia customers who has the Platform CDN entitlement added to their subscriptions.
Click Provision to provision a CDN for your environment. Acquia provisions all of the custom domains in your environment on CDN. Acquia only provisions Platform CDN for custom domains. Acquia default domains does not function on CDN. For any non-conforming domain patterns, the system displays
Note
After adding Platform CDN to your environment, Cloud Platform automatically keeps CDN configuration up-to-date. For example, when you add or remove a domain, or update an SSL certificate, you may see a CDN provisioning or updating task in the task log view. You may also see a CDN provisioning or updating task after you deploy code to an environment due to the internal operations of the system.
Testing Platform CDN
To test Platform CDN, use one of the following methods:
To test through the /etc/hosts file method:
Edit your /etc/hosts file to add a line based on the following format by using the IP address and your domain name:
Do not use the Chrome browser as it does not read the /etc/hosts file.
Some browsers require configuration to read DNS from the /etc/hosts file.
Enter the domain name in your browser and examine the page response headers.
To test through the curl command method, run the following command by using the IP address and your domain name:
curl -Is -X GET https://www.example.com --resolve www.example.com:443:151.101.1.193
Disabling Platform CDN
Important
Ensure that you point DNS to your Cloud Platform balancers before you disable CDN. This ensures that your sites remain accessible even after CDN is disabled.
In the left-hand navigation bar, click Domain Management.
On the right, click CDN.
To disable CDN for the entire environment, click Disable CDN.
Disabling Platform CDN for a single or select group of domains
To disable Platform CDN for a single or select group of custom domains, visit your DNS provider and point DNS for the chosen domain(s) to your Acquia load balancer EIP. This information is available in the Regional Origin sub-section of DNS information.
Note
As you provision Platform CDN, all your custom domains are pushed to the CDN. Domains added or removed from the Cloud Platform user interface are added or removed from CDN and remain in sync. You control which domains actually use CDN by setting each domain’s DNS records accordingly.
SSL certificates and Platform CDN
Cloud Platform supports SSL certificates on both Platform CDN and Cloud Platform balancers, enabling you to deliver fully secure experiences for your visitors. Cloud Platform automatically copies certificates to Platform CDN as part of the provisioning process. Ensure that your certificate is uploaded to Cloud Platform. Any certificates uploaded after the initial provisioning of Platform CDN are also automatically uploaded to Platform CDN.
Note
Ensure that your certificates use a 2048-bit private key before enabling Platform CDN. You can only use the certificates that are created with a 2048-bit private key.
Understanding cache invalidation
Cache invalidation is a method of displaying new content to connected clients. During invalidation, objects are marked as outdated, and the next time a client requests these objects, the client is delivered a new version. Acquia offers two approaches to cache invalidation on its Varnish-based load balancers and Platform CDN layers: Purge and Ban.
Purge requests
Purge immediately removes content from Varnish. When the client requests the data again, the request bypasses Varnish and Drupal responds to the request. This is a path-based approach. This is the primary approach for customers using Drupal 7 and the Acquia Purge module.
Ban requests
Ban adds cached object references to a list, and client requests are checked against this list to see if there are any matches. If so, new content is fetched from the application, returned to the client, and added to the cache. Cached content is updated after a client requests the information, unlike the Purge method. This is the primary approach for customers using Drupal 9 with Purge and Acquia Purge modules.
Configuring your Drupal site for cache invalidation
Follow the next steps based on your Drupal version:
Drupal 9 utilizes Drupal’s Cache API and the Purge module, both of which were architected with cache invalidation in mind. This method utilizes cache tags. Cache tags can be added to any piece of content in Drupal. With the presence of cache tags, the Purge module is able add these cache tags to a Ban list. This casts a wider net, allowing Acquia’s customers to implement a comprehensive cache invalidation strategy that caches objects for longer periods of time (TTL). When editors make content changes, it appears fresh when requested immediately.
Platform CDN respects Cache-Control and Surrogate-Control HTTP headers and tag-based invalidation. Acquia recommends using both methods as part of your application’s caching strategy.
Drupal 9 HTTP headers
Coupled with the Purge and Acquia Purge modules, the Drupal 9 cache invalidation framework expires content at Acquia Varnish and Platform CDN whenever changes occur to tagged content. This feature means that cache lifetimes at both Acquia Varnish and Platform CDN can be set to very long times and even months.
For information about how the Drupal application sets cache headers, see:
Drupal 7 does not natively support tag-based invalidation. Therefore, Acquia recommends setting Drupal’s maximum time for keeping cached assets to 60 minutes. This allows assets to remain cached for a moderate amount of time before updates are fetched from Drupal. This value can be configured downwards to ensure that your visitors receive the updated content.
To configure the maximum time, log in with administrator privileges and navigate to config/development/performance. Enable caching for anonymous users and set Expiration of cached pages to the duration you require.
These settings generate the following HTTP header:
Cache-Control: public, max-age=3600
Public means the response can be stored by all caches, including Varnish, Platform CDN, and browser caches.
Cache-Control header settings only apply to dynamic content. All static assets, such as CSS fonts, images, and JavaScript files, are given Cache-Control headers by an .htaccess directive and the Apache web infrastructure:
You can leverage Cache-Control and Surrogate-Control HTTP headers and tag-based invalidation in Javascript applications based on Node.JS.
Cache-Control works when you set it up on the server side. When you do not set up this header on the server side, the Age header increases to 3600 seconds. Here, 3600 seconds is the TTL value. For example,
To set up the Cache-Control header on the server (Acquia domain, for example, https://testdev.prod.acquia-sites.com/), run the following command and restart your server:
Note that Platform CDN takes around 30 mins for the changes to come in effect. As per the example, you can verify the changes by accessing the Acquia domain: https://testdev.prod.acquia-sites.com/. This returns the Cache-Control header in the response. After around 30 minutes, you can access the Node.js domain to view the Cache-Control header as well:
Cache clearing occurs automatically due to the Acquia Purge module.
Manually purging caches using Drupal admin
To purge all content from all caches, use Drupal’s Clear All Caches option. This also clears Acquia Varnish cache and Platform CDN cache. If the Acquia Purge module: Platform CDN purger is installed and configured correctly, you must purge all content. To do so, navigate to admin > Configuration > Performance and select the Clear all caches option.
Manually purging all caches or individual objects from Platform CDN
Important
These instructions clear content from Platform CDN only. To replace the older content with new content, purge the content from Acquia Varnish first.
Retrieve the value of service_id and token from Acquia Support.
Purge Platform CDN by running the following curl command with the token in the header and the service_id in the URL path as shown in the following example:
curl -X POST -H "Fastly-Key:<Platform CDN token>" -H "Accept: application/json" https://api.fastly.com/service/<Platform CDN Service ID>/purge_all
Use the token and Service ID values provided to you by Acquia Support.
For example,
curl -X POST -H "Fastly-Key:DMDf1ryoZiERdryIxQAb4seLOBqLfLMU" -H "Accept: application/json" https://api.fastly.com/service/4SsvFsxK25Z7t16kTqzu7d/purge_all
Navigate to your environment and click the Domains Management menu.
On the Domains tab, select Clear all caches for the domain for which you want to clear the cache.
The system clears both Acquia Varnish and Platform CDN caches.
Troubleshooting
Provisioning
If you experience issues provisioning Cloud Platform CDN, review the following likely causes:
There are no custom domains registered to your environment:
The default *.acquia-sites.com domain cannot be added to CDN. You must add at least one of your own domains before Platform CDN can be provisioned.
Your SSL/TLS certificate is not 2048-bit:
Ensure your certificates use a 2048-bit private key before enabling Platform CDN. You can only use the certificates that are created with a 2048-bit private key.
There is an older SSL/TLS certificate being served instead of a newly uploaded certificate:
Platform CDN serves a valid certificate with the closest matching CN or SAN. Deactivate any older certificates through the Cloud Platform user interface to remove them from Platform CDN.
Your domain was previously registered with Acquia’s CDN partner, Fastly Inc.:
If you have previously created a Fastly account using one of your domain names, create a Support ticket. Acquia Support will work with Fastly to transfer the domain for use on Platform CDN.
Performance
HTTP to HTTPS redirect gets stuck in a 301 redirect loop:
Ensure that your application is serving a Cache-Control header with max-age:3 or must-revalidate value. This ensures that the browser does not use its local cache.
Purge token lost or doesn’t work:
Use Drush 9 to run drush p:dia. If that command is not available, use the following method to ensure that all modules are installed and enabled:
# in your local dev environment
git clone [email protected]:manualtest.git
cd manualtest/docroot
# Use composer to install acquia_purge 1.1 beta and its dependencies
composer config minimum-stability 'beta'
composer config prefer-stable true
composer require 'drupal/acquia_purge:1.1-beta1'
# Push the code back and enable the module using drush
git add.
git commit -a -m "Add Acquia Purge module"
git push
ssh {{YOUR SSH URI HERE}}
sudo su
cd /var/www/html/{{YOUR ENVIRONMENT NAME HERE}}/docroot/
source /mnt/users/[SITEGROUP NAME]/dev.shell
drush9 en acquia_purge
yes
#>> [success] Successfully enabled: acquia_purge, purge, purge_drush
# list all the available purgers
drush9 p:purger-lsa
#>> --------------------- ---------------------------- ----------------------------------------------
#>> Plugin Label Description
#>> --------------------- ---------------------------- ----------------------------------------------
#>> acquia_purge Acquia Cloud Invalidate content from Acquia Cloud.
#>> acquia_platform_cdn Acquia Platform CDN (beta) Invalidate content from Acquia Platform CDN.
#>> --------------------- ---------------------------- ----------------------------------------------
# Enable the acquia purge and then the acquia_platform_cdn in that order to ensure
# varnish clears first and then platform_cdn clears after a short delay
drush9 p:purger-add acquia_purge
drush9 p:purger-add acquia_platform_cdn
# Enable the other purge modules that need manually enabled for some reason
drush9 pm:list | grep purge
drush9 en purge_processor_cron
drush9 en purge_processor_lateruntime
drush9 en purge_queuer_coretags
drush9 en purge_tokens
drush9 en purge_ui
drush9 en purge_drush
drush9 pm:list | grep purge
# Run the diagnostic
drush9 p:dia
Platform CDN limits and restrictions
Important
Acquia balancers have limits on request and response URL, header, and cookie sizes.
Item
Limit
Notes
Maximum vary fields
200 / 400
Exceeding the soft limit results in no error. Newer variants displace the oldest.
URL size
8 KB
Exceeding the limit results in a too long request string error.
Cookie size
32 KB
Exceeding the limit results in Fastly stripping the cookie and setting req.http.Fastly-Cookie-Overflow = “1”.
Request header size
69 KB
Depending on the circumstances, exceeding the limit can result in:
Fastly closes the client connection abruptly.
Client receives a 502 Gateway error response with an I/O error in the body.
Client receives a 503 Service Unavailable response with a Header overflow error in the body.
Response header size
69 KB
Exceeding the limit results in a 503 backend read error. See Common 503 errors for more information.
Request header count
96
Exceeding the limit results in a Header overflow error. A small portion of this limit is reserved for internal Fastly use, making the practical limit closer to 85.
Response header count
96
Exceeding the limit results in a Header overflow error. A small portion of this limit is reserved for internal Fastly use, making the practical limit closer to 85.
Surrogate key header size
16 KB
Exceeding the limit results in no error and any keys past the one that exceeds the limit, are dropped. Acquia Purge keys are 4 bytes + 1byte for the space separator, each implying a maximum of over 3000 tags per object.
Unsupported products and features
The following products and features are not supported on Platform CDN:
Acquia recommends that you do not use multiple WAFs or CDNs in front of a site while redirecting requests between those WAFs or CDNs. You can leverage Fastly-powered Platform CDN or any other WAF or CDN, including Edge Security or Edge CDN. However, Acquia does not support the use of multiple different WAFs, CDNs, or both in a layered approach.
It takes some time for provisioning to complete. It may take 10+ minutes for every Point of Presence (POP) in CDN network to update for all your domains and SSL/TLS certificates.
Once provisioning is complete, the page displays two sections: your DNS information and the status of CDN provisioning for each domain.
To begin directing visitor traffic through Platform CDN, change the authoritative DNS for your domain to point to the following endpoints:
For domains that support CNAME records, configure them to point to dualstack.acquia.map.fastly.net. The dualstack prefix in the endpoint ensures that it is IPv6 compatible without the need for a separate AAAA record.
For other domains that cannot use a CNAME record, configure at least two A records pointing to 151.101.1.193, 151.101.65.193, 151.101.129.193, or 151.101.193.193.
Navigate to Admin > Configuration > Development > Performance > Purge.
Add your purgers.
In Cache Invalidation, enable Acquia Cloud and select Acquia Platform CDN.
Note
At this point, you still have not provisioned Platform CDN. You have set up your site to send purge requests to Platform CDN. After you provision Platform CDN through the Cloud Platform user interface (see below), a return to this page shows the status on the right of this page as green for Platform CDN. If it displays in red after successful provisioning of Platform CDN, create a Support ticket.
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.
N/A
.
Note
It takes some time for provisioning to complete. It may take 10+ minutes for every Point of Presence (POP) in CDN network to update for all your domains and SSL/TLS certificates.
Once provisioning is complete, the page displays two sections: your DNS information and the status of CDN provisioning for each domain.
To begin directing visitor traffic through Platform CDN, change the authoritative DNS for your domain to point to the following endpoints:
For domains that support CNAME records, configure them to point to dualstack.acquia.map.fastly.net. The dualstack prefix in the endpoint ensures that it is IPv6 compatible without the need for a separate AAAA record.
For other domains that cannot use a CNAME record, configure at least two A records pointing to 151.101.1.193, 151.101.65.193, 151.101.129.193, or 151.101.193.193.
Navigate to Admin > Configuration > Development > Performance > Purge.
Add your purgers.
In Cache Invalidation, enable Acquia Cloud and select Acquia Platform CDN.
Note
At this point, you still have not provisioned Platform CDN. You have set up your site to send purge requests to Platform CDN. After you provision Platform CDN through the Cloud Platform user interface (see below), a return to this page shows the status on the right of this page as green for Platform CDN. If it displays in red after successful provisioning of Platform CDN, create a Support ticket.
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