Cloud Platform
Acquia Purge FAQ for Drupal 7
I have a question about setting up Acquia Purge.
This article is based on Acquia Purge 7.x-1.3.
The Acquia Purge module is designed to help you selectively target areas of your site for cache clearing. Read on for answers to some of the most common questions about this module:
The full release notes for version 7.x-1.2 are located at https://www.drupal.org/node/2527496. Version 7.x-1.3 are at https://www.drupal.org/node/2529946.
Yes, but it needs configuration. For more information, see Acquia Purge domain detection.
Yes, Acquia Purge will work without any required action. ELBs spread the traffic across your two load balancers, active-active, and Acquia Purge always purges both your primary and your passive load balancer.
That's hard to answer. Acquia Purge ensures that every single path that's being purged from Drupal will be wiped out of your two load balancers. That ensures that the CDN's "origin" (Acquia's primary LB or ELB) is fresh at all times. Acquia Purge doesn't actively wipe or purge anything on your CDN of choice, so you are dependent on how well it respects the Cache-Control header set by the pages Drupal generates. Extensive testing will be required.
Yes, it can (version 7.x-1.1 and above) once you add the following line to your settings.php file.
$conf['acquia_purge_https'] = TRUE;Important
Adding this setting will DOUBLE the total amount of purging because both http and https paths will be purged.
You'll need to monitor your website carefully as the queue can go up without getting purged fast enough. If the queue does go up quickly, consider switching to cron mode (with 1-5 minute cron intervals) or disable http:// purging as well. See the README.txt.
Yes, because that means that without your interference Acquia Purge will continue to purge http:// paths and end up double purging with high queues and resource waste as a result. By adding the following line to the settings.php file, you disable all http:// purging.
$conf['acquia_purge_http'] = FALSE;It's possible, but not recommended. By default, Acquia Purge will purge all domains it detects, including your www and your bare domain. As more domains are purged, the purging process takes longer to complete. It's best to use an .htaccess redirect from the bare to the www domain and to only purge your www domain name. For more information, see Acquia Purge domain detection.
You can visit the Status report page (Admin > Reports > Status report) to see what the status of the queue is and how many items are in it. If it's idle, it's safe to assume that it's an empty queue. You can print the full queue from a command line using drush ap-list.
Note that, if you are using the AJAX-based client-side queue processor, the queue might be empty most or all of the time. To test and find out exactly what is purged during any action (like a node edit), you could:
"$conf['acquia_purge_log_success'] = TRUE;" during your testing, and then looking at your Watchdog logs...drush ap-list to look at the queue's contents (and drush ap-process to process the queue)...drush ap-list to look at the queue's contents.Acquia Purge does not do this by default. The client-side AJAX processing works well for most websites, so adding additional cron runs isn't a required default setting, but it will improve the interval your queue is checked and proceed at. As of Acquia Purge 7.x-1.0, it is possible to add this to your settings.php file:
$conf['acquia_purge_cron'] = TRUE;This lets the module purge from cron. It is very important (if your cron processing gs through Drush) that the --uri parameter gets passed in to Drush; it should point to a URL your end users will also visit, such as your front page.
drush --uri=http://... ap-processNo, this is not possible. It serves as last resort when nothing else processes the queue. It takes processing out of the main HTTP requests, which helps to ensure a fast Drupal backend experience. However, it can be visually hidden by revoking the purge on-screen permission, or for every user including the administrator by adding $conf['acquia_purge_silentmode'] = TRUE; to the settings.php file.
The Purge module, co-written by Acquian Paul Krischer, is not designed specifically for Acquia Cloud. Supporting it becomes more difficult because our products change over time. In the future, Purge will be redesigned to be technology-agnostic. This will make it possible for this module to become one of Acquia Purge's platform plugins, while sharing a common infrastructure. The use of Purge on Acquia Cloud is discouraged.
Yes, it is possible, but not supported.
Cache invalidation is incredibly hard and it is more than a simple HTTP PURGE/BAN request when nodes are saved. Supporting multiple hosting environments would call for a serious API that currently neither the Acquia Purge or Purge module can support. Beyond this limitation, purging paths works but isn't as elegant as it will become in Drupal 8. We built a focused and working module for Acquia Cloud customers but can't support cases where this module is used outside of our platform.
In Drupal 8, things will get inherently better as its whole architecture supports reverse proxies. All pages and URLs Drupal 8 generates are tagged with short strings that represent everything that's rendered into HTML and includes things as entities, menu items, blocks and more. Whenever content changes, the tag is invalidated which external proxies like Varnish can also support with features like BAN. The Purge module for Drupal 8 will provide a proper API and its submodules will provide the necessary plugins to make it work on all environments.
Acquia Cloud can be configured to think it is on Acquia Cloud and that will make its diagnostic message go silent. The HTTP requests it makes should work on most Varnish configurations. If it doesn't, it is up to you to bring things in line and potentially patch the module if necessary.
// Trick Acquia Purge into thinking we are on Acquia Cloud. $_ENV['AH_SITE_NAME'] = $_ENV['AH_SITE_GROUP'] = 'fake'; $_ENV['AH_SITE_ENVIRONMENT'] = 'fake'; $conf['reverse_proxies'] = array('127.0.0.1');We removed the Report cache purges setting that became redundant once the Purge notification permission was added. The progress bar now always shows for administrators because Drupal's permission system allows everything for administrators. In general, you shouldn't use admin to edit content.
Yes, absolutely! Before Acquia Purge was an official project, there was a branch called queuing-elb-support that many customers used. It was the predecessor of the current queuing-based engine. It allowed too many domains to be purged in combination with a significant payload on Drupal's queue table. That caused the database to crash and purges to be very slow. As of 7.x-1.0-alpha2, the module processes up to six purges in parallel, reducing the database payload drastically. As of version 7.x-1.0-alpha3, many built-in diagnostic tests protect sites against issues from the past.
The Acquia Purge module purges whatever it's being told to purge by either the Cache Expiration module, a rule action, or custom code. The Cache Expiration module has the difficult task of detecting which pages need to be wiped based on changing entities (such as nodes, taxonomy, and menu items). However, it can't detect your views or other custom paths specific to your site and will therefore almost always mi pieces.
Originally, a rule action called Purge a path from Varnish on Acquia Cloud shipped with Acquia Purge prior to version 7.x-1.0. This is still available but no longer recommended for use on websites. The obsolete rule action now maps its behavior to the new rule action Clear pages on Acquia Cloud and therefore also supports URLs. If your site has rules using the obsolete rule, you will get periodic error messages in your logs because it will be deleted in the future.
Note: This section applies to Acquia Purge versions prior to 7.x-1.1.
The Acquia Purge module exposes a rule action named Purge a path from Varnish on Acquia Cloud, which allows you to include purged paths like news, news?page=1, and contact. For instance, whenever content of type news changes, you can include the news view and the first five to ten pages.
It got renamed and now gets re-implemented by the Acquia Purge module, because we learned that it confused many users and was also less efficient as it mangled paths through all of Expire's code. The rule got renamed into 'Clear pages on Acquia Cloud' and is the only one rule action you should use now.
This is not currently possible. There is an open feature request (drupal.org issue).
Because it will be ineffective. The main reason for implementing the Cache Expiration module and Acquia Purge is that you can increase the value of this setting up to many hours, a day, or even months. Once this setting is set to a reasonable value, all pages served by Drupal will be kept in Varnish as long as possible, and anonymous traffic won't cause your Drupal site to bootstrap. This leaves your Acquia Cloud web servers available for other important resource needs, like editors, site administrators, or cron.
Yes, performance will improve dramatically once you've increased your Expiration of cached pages setting to a high value (days rather than hours). The higher the expiration is set, the higher the time limit in the Cache-Control HTTP response header will be set. That will make your Acquia Cloud site's Varnish instances keep the pages in cache longer and free up many PHP processing slots on your web servers.
Acquia Purge will always queue pages that have a purge request set by an expire. Anonymous users commenting on a page can trigger an expire. However, an anonymous user will never trigger the AJAX-based client-side processor. This prevents exposing Acquia Purge as a public DDOS-tool. Comments and other anonymously queued paths will be purged either as soon as a logged-in user triggers a purge or when the drush ap-process is called.
Yes, don't even consider doing this. Occasionally, we find a site that has a client-side script that contacts Drupal with unique request URLs (for example, /mycallback?t=1384274831). Because both Varnish and Drupal's page cache see the full absolute URL as the unique identifier on which to base caching, a randomly changing URL will continuously bypass your caching mechanisms and can seriously impact performance.
drush ap-process in cron; is this okay?Yes, but there are changes that may affect whether you want to use it. Acquia Purge now has a cleaner way of enabling cron-based purging with the following setting in your settings.php file:
$conf['acquia_purge_cron'] = TRUE;This is the recommended way of achieving cron-based purging. The drawback to that method is that there's no granular control over when purging happens (as it follows the cron schedule) and that it also disables the client-side progress bar. Consider using the new method, but if any of its drawbacks prevent you from using the new cron feature, you can continue using the previous method.
This can be a side effect of using Acquia Purge. Logging is meant to help keep a trail for when things go bad and also to confirm if things work, which is especially helpful for those new to this module and still in the process of setting it up. But if your site is stable and fine with Acquia Purge, it makes sense to reduce records in your logs by setting "$conf['acquia_purge_log_success'] = FALSE;", which will suppress reporting successful purges but will still log any failure.
Yes, the module has been purely designed to purge things on Acquia Cloud and to do it well! Its relation with the Cache Expiration module is very thin; for instance, it receives paths and wraps those to its own publicly facing API functions.
You can queue items for purging like this:
$service = _acquia_purge_service(); $service->addPath('node/5?parameter'); $service->addPaths(array('news/section1', 'contact'));If you run the preceeding code as an authenticated user during a web request (not through Drush), it will trigger the AJAX processor for that user's next page load. If you want to process directly, you can work a chunk from the queue with this:
$service = _acquia_purge_service(); if ($service->lockAcquire()) { $service->process(); $service->lockRelease(); }The AcquiaPurgeService::process() call will run as long as PHP has resources for and depends on Acquia Purge's internal capacity calculation. When it runs from the CLI, it has a higher max_execution_time and will therefore more at once, then it will when triggered through a web server.
You can check the queue state by querying:
var_dump(_acquia_purge_queue_stats());No, never.
If you have any questions or comments about the module for its maintainer, or you've found a bug or some other issue, you can file an issue in the Acquia Purge issue queue .
Cloud Platform