Information for: DEVELOPERS   PARTNERS   SUPPORT

Preparing for a successful launch

This checklist will help you track the tasks you must complete to successfully launch an application on Cloud Platform.

Configuring SSL

The following tasks are common requirements for building an application that supports SSL.

  Task Why
Generate Certificate Signing Request (CSR) A CSR is required to buy an SSL certificate. If you have already purchased an SSL cert, you can skip this step
Upload SSL certificate If there is no SSL installed, your website will throw an error when accessed over HTTPS
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

Prepare for successful website launch

The following performance and scalability tasks prepare your application for production traffic.

  Task Why
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
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
Disable basic authentication so Acquia can check that Varnish is serving pages from cache With basic authentication enabled, Acquia can’t check whether Varnish caching is working
Update Drupal Core to the latest release Security vulnerabilities leave your website more susceptible to attacks, and so forth
Disable any modules that set session cookies Session cookies can prevent Varnish from working properly, and lead to severe performance issues
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 an Acquia Support ticket. Conditionally overriding the memory limit for certain administration pages can sometimes be acceptable, but check with Acquia Support before adding this)
Configure memcache to help with overall website performance The lack of memcache can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance
Sanitize code variables Ensure variables are being wrapped correctly to prevent cross-site scripting, forgery attacks, and more
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
Disable database logging module The DBlog modules 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
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
Remove SQL queries and PHP logic or functions Going against the Drupal architecture can cause performance problems (for example, 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
Clear Stage Varnish caches Clearing cache on your staging website will allow the most recent website changes to be reflected
Migrate Stage code to Prod Without code in your production environment, there will be no live website
Migrate Stage file to Prod Without files in your production environment, there will be no live website. For more information, see Copying files between environments.
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.
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
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
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
Identify and remediate potential issues from having large 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
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
Disable page_compression (Drupal 7 only) Drupal 7’s Compress cached pages option (page_compression) can cause unexpected behavior when an external cache such as Varnish is employed, and typically provides no benefit; so, Compress cached pages should be disabled
Use InnoDB instead of MyISAM for database tables Acquia recommends the use of InnoDB over MyISAM. There are several reasons that InnoDB is the preferred engine for MySQL databases
Set the minimum cache lifetime to none (Drupal 7 only) The minimum cache lifetime prevents Drupal from clearing webpages and block caches for a period of time after changes are made. If set to greater than none, changes won’t be readily visible
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
Ensure variable_set or cache_clear_all isn’t overused (Drupal 7 only) On a Drupal 7 website excessive use of variable_set or cache_clear_all can cause flaws in caching and therefore create performance issues
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
Enable Fast 404
(Drupal 7 only)

Processing 404 messages effectively can have a significant impact on website performance. Requests resulting in an HTTP 404 bypass Varnish caching and request data from the infrastructure directly.

This is a Drupal 7 recommendation. Fast 404 is in alpha for Drupal 9.

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 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
Identify and Block Nuisance Bots Nuisance bots disrupt site analytics and create an outsize impact on your infrastructure utilization. Add such nuisance bots to .htaccess to keep unnecessary traffic at bay.

Get production-ready

These configuration tasks configure preferences and connect your application to Acquia services.

  Task Why
Add custom domains If there are no custom domains present, domains won’t resolve when DNS is updated
Configure Remote Administration preferences Setting your application update preferences correctly ensures security updates can be integrated into your workflow

Complete final go-live steps

These tasks prepare your application for an imminent launch.

  Task Why
Clear the Varnish cache on your production environment Clearing cache on your production environment will allow the most recent website changes to be reflected
Backup 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
Enable Production mode Lack of production mode leads to a heightened possibility of destroying your live application by overwriting your production files and databases
Check that domains and DNS are pointed correctly Your website won’t resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address