Cloud Platform
Preparing for a successful launch
| A CSR is required to buy an SSL certificate. If you have already purchased an SSL certificate, you can skip this step. |
| Generating a certificate signing request (CSR) |
| Upload SSL certificate | If there is no SSL installed, your website will throw an error when accessed over HTTPS. | Managing SSL certificates |
| Check rewrite rules are configured (using a contributed module or .htaccess file) | Your application’s .htaccess file controls how your website’s visitors can access your website and can be configured to handle many different visitor scenarios. | Introduction to .htaccess rewrite rules |
The following performance and scalability tasks prepare your application for production traffic.
| Task | Why | Documentation |
|---|---|---|
| Perform final content migration | After content freeze, migrate content one last time, if applicable. | |
| Delete test content | Delete or verify the deletion of any test content. | |
| Index content | After content freeze, index content for Acquia Search. | |
| Verify Search | Make sure search is working properly on production. | |
| Identify missing content/assets and broken links | Consider using the link checker module or use some other crawler. | Link checker | Drupal.org |
| 404 Remediation | Resolve 404s (add missing content/assets, update broken links, etc.). | |
| 301 Remediation | Create redirects as needed (Redirect module, .htaccess rules, etc.). | Redirect | Drupal.org |
| Configure sitemap | Set up and configure a module like Sitemap XML to serve. | XML sitemap | Drupal.org |
| 404 handling | Create a plan for remediating 404s post-launch. | Redirect | Drupal.org |
| Task | Why | Documentation |
|---|---|---|
| Configure Teams and Permissions | Ensure that everyone that needs access to Acquia Cloud has the necessary permissions. | Managing team members |
| Configure Drupal cron using Scheduled jobs | Set up the necessary cron jobs for your application to perform regular system maintenance and scheduled tasks. | Using scheduled jobs to support your application |
| Configure New Relic | To see application performance metrics for requests that reach Drupal. | Claiming your New Relic APM Pro account |
| Configure Platform Email | Allow your application to send outbound email on verified domain names. | Configuring Platform Email |
| Task | Why | Documentation |
|---|---|---|
| Address issues identified in the Site Review | Site Review is provided by Acquia Support or your TAM. | |
| Address issues identified in Drupal Status Report | Check /admin/reports/status. | |
| Cache test | Verify pages have correct cache headers. | Caching Score |
| Front end performance testing | Use PageSpeed Insights, YSlow, and WebPageTest. | PageSpeed Insights | YSlow | WebPageTest |
| Load testing | Confirm estimated monthly page views and load test data to make sure infrastructure is sized properly. Use a tool like BlazeMeter. | Load testing on Cloud Platform | BlazeMeter |
| Check logs for errors and notices | Resolve any errors and notices. | About Cloud Platform logging |
| Accessibility testing | Review site for accessibility compliance. | Website Content Optimization & Governance Platform |
| Task | Why | Documentation |
|---|---|---|
| Identify DNS owner | Determine who has the authority/ability to manage DNS. | Configuring DNS records for your application |
| Verify Domains and DNS | Make sure Domains and DNS info have been identified. | Managing domains |
| Verify edit domain | Ensure the edit domain is functional for content admins. | Best practices on setting up an edit domain |
| Set a short TTL for DNS | If using an existing domain, ensure the TTL is set to 5 minutes prior to launch. This ensures a quick launch process. | Set a short TTL for DNS |
| Task | Why | Documentation |
|---|---|---|
| Submit a Site Review ticket (2+ weeks before website launch) | The Site Review will be conducted by Acquia once you confirm you have launch-ready code in the production environment. | Contact Acquia Support |
| Set page cache maximum age to something greater than “no caching” | Varnish® won’t cache your standard page requests from Drupal if page cache maximum age isn’t set. This may cause severe strain on infrastructure, resulting in degraded performance and potential website downtime. | Configuring Drupal cache settings for Varnish |
| Enable & configure Acquia Purge module | Acquia Purge is essential for proactively clearing stale content from Varnish® cache and Platform CDN caches, if applicable. | Purging Varnish cache on Acquia Cloud |
| Disable basic authentication so Acquia can check that Varnish is serving pages from cache | With basic authentication enabled (typically using the Shield module), you can’t check whether Varnish caching is working. | Password-protecting non-production environments |
| Update Drupal Core to the latest release | Security vulnerabilities leave your website more susceptible to attacks, and so on. |
|
| Disable any modules that set session cookies | Session cookies can prevent Varnish from working properly and lead to severe performance issues. This will be checked in an Acquia Site Review. | Using Varnish |
| Don’t override the PHP memory limit on a global basis. Consider conditionally increasing memory limits for specific pages that need more memory | Acquia tunes its infrastructure to use the exact number of threads possible for 128 MB of PHP memory. If your application needs more memory for every page request, create a Support ticket. Conditionally overriding the memory limit for certain administration pages can sometimes be acceptable, but check with Acquia Support before adding this. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Configure Memcache to help with overall website performance | The lack of Memcached can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance. | Enabling Memcached on Cloud Platform |
| Enable the Dynamic Page Cache module | Dynamic Page Cache may increase the speed of your website, even for authenticated users. It’s the second line of defense after reverse-proxy caching (Varnish) and will keep user requests from overwhelming your website until the latter is warmed up. | |
| Enable JavaScript / CSS aggregation | CSS and JavaScript files can cause extended page load times because it is loading all the files for each. This can slow down page rendering. | Improving application performance |
| Disable Watchdog database logging module | The DBlog module (watchdog) writes logs to the database, which can cause a major strain on storage and memory. | |
| Enable the Syslog module | Syslog should be used in favor of DBLog. It can store logs much faster because it doesn’t need to write to the database. | About Cloud Platform logging |
| Check for pending database updates | Depending on the functionality, issues can compound over time if left unaddressed. This is important for critical/core business functionality. | |
| Enable full PHP error reporting | Failure to log problems caused by faults in PHP can cripple your ability to troubleshoot an issue. | PHP error logs |
| Check for and Remove SQL queries and PHP logic or functions in templates | Going against the Drupal architecture can cause performance problems, such as SQL queries should not exist in Drupal templates such as node--xxx.tpl.php. | |
| Back up Stage and Prod database | For recovery purposes. In the event of a disaster, you can quickly retrieve the most current version of your database. | Taking backups |
| Clear Stage Varnish caches | Clearing cache on your staging website will allow the most recent website changes to be reflected. | Using Varnish |
| Migrate Stage code to Prod | Without code in your production environment, there will be no live website. | Code workflows with Cloud Platform |
| Migrate Stage files to Prod | Without files in your production environment, there will be no live website. For more information, see Copying files between environments. | Working with files | Cloud Platform |
| Migrate Stage database to Prod | Without a database in your production environment, there will be no live website. For more information, see Copying a database across environments. | Working with databases |
| Review areas of codebase using infrastructure-side device detection to confirm caching isn’t impacted or remove entirely | If the website is relying on infrastructure-side device detection for anonymous visitors, you may find pages are improperly caching for a single device. | Varnish headers |
| Configure OPCache to be large enough to store compiled code for your applications’ PHP scripts | If OPCache usage is too high, you may experience memory allocation and other associated OPCache errors. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Ensure directories don’t contain more than 2,500 files each | Website performance can severely degrade when too many files are added and available to the system in a single directory without any subdirectory structure. | Proactively organizing files in subfolders |
| Identify and remediate potential issues from having large image files | Image processing can be complex and can put a major hit on website resources (for example, memory). Underestimating the memory usage of these processes can have severe impacts on the responsiveness of your website. | Scoping the impact of image processing |
| Disable or adjust settings for modules and applications | Cloud Platform and security require permissions and installs to be built in a particular fashion. This can sometimes cause incompatibilities with Drupal contributed modules. | Modules and applications incompatible with Cloud Platform |
| Switch from Drupal database search to Acquia Search | This can cause availability issues for websites in association with increased database activity, and is considered redundant and inferior to search backed by Acquia Search. | Acquia Search |
| Enable caching on blocks, views, and panels where applicable | While Varnish cache will take a significant load off your website, Drupal-level granular caching can provide more performance benefits in many situations. | |
| Disable default Drupal cron in favor of Acquia’s scheduled jobs | Compared to other cron solutions, using the Scheduled Jobs page is more reliable and provides extensive and integrated logging for Cloud Platform applications; disable the automatic cron module. | Using scheduled jobs to support your application |
| Disable unneeded modules (SimpleTest, Statistics, Devel, Mobile Tools) in Production | These modules can increase the website’s startup (bootstrap) overhead and are unnecessary in Production. | |
| Disable user interface modules (views_ui and field_ui) | Can impose a small performance penalty when enabled, and can allow the essential views/fields required by your website to be modified. https://Blocking unwanted traffic on your website | |
| Identify and Block Nuisance Bots | Nuisance bots disrupt site analytics and create an impact on your infrastructure utilization. Block unwanted traffic with a WAF. Add such nuisance bots to .htaccess to keep unnecessary traffic at bay. | Blocking unwanted traffic on your website |
These configuration tasks configure preferences and connect your application to Acquia services.
| Task | Why | Documentation |
|---|---|---|
| Add custom domains | If there are no custom domains present, domains do not resolve when DNS is updated. Include the bare domain if necessary. | Managing domains |
| Configure Remote Administration preferences | Setting your application update preferences correctly ensures security updates can be integrated into your workflow. | Remote Administration Preferences |
These tasks prepare your application for an imminent launch.
| Task | Why | Documentation |
|---|---|---|
| Remove Prod environment site protection | Disable basic auth (Shield module) or remove IP whitelists. | Password-protecting non-production environments |
| Warm Caches using /etc/hosts and Prod domain | Configure /etc/hosts and navigate the site as anonymous to cache popular pages. | Avoiding maintenance mode during site updates |
| Clear the Varnish cache on your production environment | Clearing cache on your production environment will allow the most recent website changes to be reflected. | Using Varnish |
| Back up the database on your production environment | For recovery purposes. In the event of a disaster, you can retrieve the most current version of your database readily. | Taking backups |
| Enable Production mode | Lack of a production mode leads to a heightened possibility of destroying your live application by overwriting your production files and databases. | Using Production mode to protect your live application |
| Check that domains and DNS are pointed correctly | Your website do not resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address. | Configuring DNS records for your application |
| Enable legacy 301 Redirects | Enable 301 redirects from legacy URLs/services/sites to the new site. | Redirect |
| Notify search engines of the site | Such as Google Webmaster Tools. | Google Search Console |
These items should be checked and verified once the site has been moved to production.
| Task | Notes | Documentation |
|---|---|---|
| Check Drupal’s status report | Go to Reports > Status report. | |
| Verify analytics tracking is working | ||
| Verify third-party integrations are working | Any external app or service that interacts with Drupal needs to be verified. | |
| Monitor New Relic | File an Acquia Support case with any concerns. Paste a permalink to what you see in New Relic in the case. | Using New Relic to troubleshoot site issues |
| Monitor Stack Metrics | Verify that infrastructure metrics are good. | Using Stack Metrics to monitor activity on your environments |
| Request Traffic Report | Acquia Support can provide a traffic report upon request. This shows the top 200, 30x, 40x, and 50x requests. | Contact Acquia Support |
| Verify 301 redirects | Make sure redirects are working properly. | Redirects |
| Verify emails are being sending correctly | Troubleshooting Platform Email | |
| Verify cron jobs are executing properly | Using scheduled jobs to support your application |
In case there are unforeseen or unplanned issues, the steps below can be followed to revert the launch and go back to using the old site.
| Task | Notes | Documentation |
|---|---|---|
| Change DNS | Point DNS back to the original site. | |
| Revert 301 Redirects | Redirect | |
| Enable the Shield module on Prod environment | ||
| Flush Varnish cache | Flushing Varnish prevents the site from being displayed even though the Shield module is enabled. | Using Varnish |
| Notify necessary parties of postponed launch |
If this content did not answer your questions, try searching or contacting our support team for further assistance.
| Generating a certificate signing request (CSR) |
| Upload SSL certificate | If there is no SSL installed, your website will throw an error when accessed over HTTPS. | Managing SSL certificates |
| Check rewrite rules are configured (using a contributed module or .htaccess file) | Your application’s .htaccess file controls how your website’s visitors can access your website and can be configured to handle many different visitor scenarios. | Introduction to .htaccess rewrite rules |
The following performance and scalability tasks prepare your application for production traffic.
| Task | Why | Documentation |
|---|---|---|
| Perform final content migration | After content freeze, migrate content one last time, if applicable. | |
| Delete test content | Delete or verify the deletion of any test content. | |
| Index content | After content freeze, index content for Acquia Search. | |
| Verify Search | Make sure search is working properly on production. | |
| Identify missing content/assets and broken links | Consider using the link checker module or use some other crawler. | Link checker | Drupal.org |
| 404 Remediation | Resolve 404s (add missing content/assets, update broken links, etc.). | |
| 301 Remediation | Create redirects as needed (Redirect module, .htaccess rules, etc.). | Redirect | Drupal.org |
| Configure sitemap | Set up and configure a module like Sitemap XML to serve. | XML sitemap | Drupal.org |
| 404 handling | Create a plan for remediating 404s post-launch. | Redirect | Drupal.org |
| Task | Why | Documentation |
|---|---|---|
| Configure Teams and Permissions | Ensure that everyone that needs access to Acquia Cloud has the necessary permissions. | Managing team members |
| Configure Drupal cron using Scheduled jobs | Set up the necessary cron jobs for your application to perform regular system maintenance and scheduled tasks. | Using scheduled jobs to support your application |
| Configure New Relic | To see application performance metrics for requests that reach Drupal. | Claiming your New Relic APM Pro account |
| Configure Platform Email | Allow your application to send outbound email on verified domain names. | Configuring Platform Email |
| Task | Why | Documentation |
|---|---|---|
| Address issues identified in the Site Review | Site Review is provided by Acquia Support or your TAM. | |
| Address issues identified in Drupal Status Report | Check /admin/reports/status. | |
| Cache test | Verify pages have correct cache headers. | Caching Score |
| Front end performance testing | Use PageSpeed Insights, YSlow, and WebPageTest. | PageSpeed Insights | YSlow | WebPageTest |
| Load testing | Confirm estimated monthly page views and load test data to make sure infrastructure is sized properly. Use a tool like BlazeMeter. | Load testing on Cloud Platform | BlazeMeter |
| Check logs for errors and notices | Resolve any errors and notices. | About Cloud Platform logging |
| Accessibility testing | Review site for accessibility compliance. | Website Content Optimization & Governance Platform |
| Task | Why | Documentation |
|---|---|---|
| Identify DNS owner | Determine who has the authority/ability to manage DNS. | Configuring DNS records for your application |
| Verify Domains and DNS | Make sure Domains and DNS info have been identified. | Managing domains |
| Verify edit domain | Ensure the edit domain is functional for content admins. | Best practices on setting up an edit domain |
| Set a short TTL for DNS | If using an existing domain, ensure the TTL is set to 5 minutes prior to launch. This ensures a quick launch process. | Set a short TTL for DNS |
| Task | Why | Documentation |
|---|---|---|
| Submit a Site Review ticket (2+ weeks before website launch) | The Site Review will be conducted by Acquia once you confirm you have launch-ready code in the production environment. | Contact Acquia Support |
| Set page cache maximum age to something greater than “no caching” | Varnish® won’t cache your standard page requests from Drupal if page cache maximum age isn’t set. This may cause severe strain on infrastructure, resulting in degraded performance and potential website downtime. | Configuring Drupal cache settings for Varnish |
| Enable & configure Acquia Purge module | Acquia Purge is essential for proactively clearing stale content from Varnish® cache and Platform CDN caches, if applicable. | Purging Varnish cache on Acquia Cloud |
| Disable basic authentication so Acquia can check that Varnish is serving pages from cache | With basic authentication enabled (typically using the Shield module), you can’t check whether Varnish caching is working. | Password-protecting non-production environments |
| Update Drupal Core to the latest release | Security vulnerabilities leave your website more susceptible to attacks, and so on. |
|
| Disable any modules that set session cookies | Session cookies can prevent Varnish from working properly and lead to severe performance issues. This will be checked in an Acquia Site Review. | Using Varnish |
| Don’t override the PHP memory limit on a global basis. Consider conditionally increasing memory limits for specific pages that need more memory | Acquia tunes its infrastructure to use the exact number of threads possible for 128 MB of PHP memory. If your application needs more memory for every page request, create a Support ticket. Conditionally overriding the memory limit for certain administration pages can sometimes be acceptable, but check with Acquia Support before adding this. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Configure Memcache to help with overall website performance | The lack of Memcached can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance. | Enabling Memcached on Cloud Platform |
| Enable the Dynamic Page Cache module | Dynamic Page Cache may increase the speed of your website, even for authenticated users. It’s the second line of defense after reverse-proxy caching (Varnish) and will keep user requests from overwhelming your website until the latter is warmed up. | |
| Enable JavaScript / CSS aggregation | CSS and JavaScript files can cause extended page load times because it is loading all the files for each. This can slow down page rendering. | Improving application performance |
| Disable Watchdog database logging module | The DBlog module (watchdog) writes logs to the database, which can cause a major strain on storage and memory. | |
| Enable the Syslog module | Syslog should be used in favor of DBLog. It can store logs much faster because it doesn’t need to write to the database. | About Cloud Platform logging |
| Check for pending database updates | Depending on the functionality, issues can compound over time if left unaddressed. This is important for critical/core business functionality. | |
| Enable full PHP error reporting | Failure to log problems caused by faults in PHP can cripple your ability to troubleshoot an issue. | PHP error logs |
| Check for and Remove SQL queries and PHP logic or functions in templates | Going against the Drupal architecture can cause performance problems, such as SQL queries should not exist in Drupal templates such as node--xxx.tpl.php. | |
| Back up Stage and Prod database | For recovery purposes. In the event of a disaster, you can quickly retrieve the most current version of your database. | Taking backups |
| Clear Stage Varnish caches | Clearing cache on your staging website will allow the most recent website changes to be reflected. | Using Varnish |
| Migrate Stage code to Prod | Without code in your production environment, there will be no live website. | Code workflows with Cloud Platform |
| Migrate Stage files to Prod | Without files in your production environment, there will be no live website. For more information, see Copying files between environments. | Working with files | Cloud Platform |
| Migrate Stage database to Prod | Without a database in your production environment, there will be no live website. For more information, see Copying a database across environments. | Working with databases |
| Review areas of codebase using infrastructure-side device detection to confirm caching isn’t impacted or remove entirely | If the website is relying on infrastructure-side device detection for anonymous visitors, you may find pages are improperly caching for a single device. | Varnish headers |
| Configure OPCache to be large enough to store compiled code for your applications’ PHP scripts | If OPCache usage is too high, you may experience memory allocation and other associated OPCache errors. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Ensure directories don’t contain more than 2,500 files each | Website performance can severely degrade when too many files are added and available to the system in a single directory without any subdirectory structure. | Proactively organizing files in subfolders |
| Identify and remediate potential issues from having large image files | Image processing can be complex and can put a major hit on website resources (for example, memory). Underestimating the memory usage of these processes can have severe impacts on the responsiveness of your website. | Scoping the impact of image processing |
| Disable or adjust settings for modules and applications | Cloud Platform and security require permissions and installs to be built in a particular fashion. This can sometimes cause incompatibilities with Drupal contributed modules. | Modules and applications incompatible with Cloud Platform |
| Switch from Drupal database search to Acquia Search | This can cause availability issues for websites in association with increased database activity, and is considered redundant and inferior to search backed by Acquia Search. | Acquia Search |
| Enable caching on blocks, views, and panels where applicable | While Varnish cache will take a significant load off your website, Drupal-level granular caching can provide more performance benefits in many situations. | |
| Disable default Drupal cron in favor of Acquia’s scheduled jobs | Compared to other cron solutions, using the Scheduled Jobs page is more reliable and provides extensive and integrated logging for Cloud Platform applications; disable the automatic cron module. | Using scheduled jobs to support your application |
| Disable unneeded modules (SimpleTest, Statistics, Devel, Mobile Tools) in Production | These modules can increase the website’s startup (bootstrap) overhead and are unnecessary in Production. | |
| Disable user interface modules (views_ui and field_ui) | Can impose a small performance penalty when enabled, and can allow the essential views/fields required by your website to be modified. https://Blocking unwanted traffic on your website | |
| Identify and Block Nuisance Bots | Nuisance bots disrupt site analytics and create an impact on your infrastructure utilization. Block unwanted traffic with a WAF. Add such nuisance bots to .htaccess to keep unnecessary traffic at bay. | Blocking unwanted traffic on your website |
These configuration tasks configure preferences and connect your application to Acquia services.
| Task | Why | Documentation |
|---|---|---|
| Add custom domains | If there are no custom domains present, domains do not resolve when DNS is updated. Include the bare domain if necessary. | Managing domains |
| Configure Remote Administration preferences | Setting your application update preferences correctly ensures security updates can be integrated into your workflow. | Remote Administration Preferences |
These tasks prepare your application for an imminent launch.
| Task | Why | Documentation |
|---|---|---|
| Remove Prod environment site protection | Disable basic auth (Shield module) or remove IP whitelists. | Password-protecting non-production environments |
| Warm Caches using /etc/hosts and Prod domain | Configure /etc/hosts and navigate the site as anonymous to cache popular pages. | Avoiding maintenance mode during site updates |
| Clear the Varnish cache on your production environment | Clearing cache on your production environment will allow the most recent website changes to be reflected. | Using Varnish |
| Back up the database on your production environment | For recovery purposes. In the event of a disaster, you can retrieve the most current version of your database readily. | Taking backups |
| Enable Production mode | Lack of a production mode leads to a heightened possibility of destroying your live application by overwriting your production files and databases. | Using Production mode to protect your live application |
| Check that domains and DNS are pointed correctly | Your website do not resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address. | Configuring DNS records for your application |
| Enable legacy 301 Redirects | Enable 301 redirects from legacy URLs/services/sites to the new site. | Redirect |
| Notify search engines of the site | Such as Google Webmaster Tools. | Google Search Console |
These items should be checked and verified once the site has been moved to production.
| Task | Notes | Documentation |
|---|---|---|
| Check Drupal’s status report | Go to Reports > Status report. | |
| Verify analytics tracking is working | ||
| Verify third-party integrations are working | Any external app or service that interacts with Drupal needs to be verified. | |
| Monitor New Relic | File an Acquia Support case with any concerns. Paste a permalink to what you see in New Relic in the case. | Using New Relic to troubleshoot site issues |
| Monitor Stack Metrics | Verify that infrastructure metrics are good. | Using Stack Metrics to monitor activity on your environments |
| Request Traffic Report | Acquia Support can provide a traffic report upon request. This shows the top 200, 30x, 40x, and 50x requests. | Contact Acquia Support |
| Verify 301 redirects | Make sure redirects are working properly. | Redirects |
| Verify emails are being sending correctly | Troubleshooting Platform Email | |
| Verify cron jobs are executing properly | Using scheduled jobs to support your application |
In case there are unforeseen or unplanned issues, the steps below can be followed to revert the launch and go back to using the old site.
| Task | Notes | Documentation |
|---|---|---|
| Change DNS | Point DNS back to the original site. | |
| Revert 301 Redirects | Redirect | |
| Enable the Shield module on Prod environment | ||
| Flush Varnish cache | Flushing Varnish prevents the site from being displayed even though the Shield module is enabled. | Using Varnish |
| Notify necessary parties of postponed launch |
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform