Cloud Platform

Preparing for a successful launch

Best practices

Prior to launching your site, ensure the following:

  • Do not launch on Fridays.
  • Verify that all contributed and core dependencies are up to date and secure.
  • Disable all development and UI modules in the production environment.
  • Disable the Shield module in the production environment.
  • Create a Support ticket to notify Acquia of your upcoming launch.

In addition to the preceding best practices, follow the subsequent detailed checklist that can 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.

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 certificateIf 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.

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
Enable & configure Acquia Purge moduleAcquia Purge is essential for proactively clearing stale content from Varnish® cache, and Platform CDN caches if applicable.
Disable basic authentication so Acquia can check that Varnish is serving pages from cacheWith basic authentication enabled, Acquia can’t check whether Varnish caching is working
Update Drupal Core to the latest releaseSecurity vulnerabilities leave your website more susceptible to attacks, and so forth
Disable any modules that set session cookiesSession 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 memoryAcquia 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)
Configure memcache to help with overall website performanceThe lack of memcache can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance
Sanitize code variablesEnsure variables are being wrapped correctly to prevent cross-site scripting, forgery attacks, and more
Enable the Dynamic Page Cache moduleDynamic 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 aggregationCSS 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 moduleThe DBlog modules writes logs to the database, which can cause a major strain on storage and memory
Enable the Syslog moduleSyslog 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 updatesDepending on the functionality, issues can compound over time if left unaddressed. This is important for critical/core business functionality
Enable full PHP error reportingFailure to log problems caused by faults in PHP can cripple your ability to troubleshoot an issue
Remove SQL queries and PHP logic or functionsGoing against the Drupal architecture can cause performance problems (for example, node--xxx.tpl.php)
Back up Stage and Prod databaseFor recovery purposes. In the event of a disaster, you can quickly retrieve the most current version of your database
Clear Stage Varnish cachesClearing cache on your staging website will allow the most recent website changes to be reflected
Migrate Stage code to ProdWithout code in your production environment, there will be no live website
Migrate Stage file to ProdWithout files in your production environment, there will be no live website. For more information, see Copying files between environments.
Migrate Stage database to ProdWithout 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 entirelyIf 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 scriptsIf 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 eachWebsite 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 filesImage 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 applicationsCloud Platform and security require permissions and installs to be built in a particular fashion. This can sometimes cause incompatibilities with Drupal contributed modules
Use InnoDB instead of MyISAM for database tablesAcquia recommends the use of InnoDB over MyISAM. There are several reasons that InnoDB is the preferred engine for MySQL databases
Switch from Drupal database search to Acquia SearchThis can cause availability issues for websites in association with increased database activity, and is considered redundant and inferior to search backed by Acquia Search
Enable caching on blocks, views, and panels where applicableWhile 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 jobsCompared 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 ProductionThese 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 BotsNuisance 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.

Add custom domainsIf there are no custom domains present, domains won’t resolve when DNS is updated
Configure Remote Administration preferencesSetting 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.

Clear the Varnish cache on your production environmentClearing cache on your production environment will allow the most recent website changes to be reflected
Backup the database on your production environmentFor recovery purposes. In the event of a disaster, you can retrieve the most current version of your database readily
Enable Production modeLack 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 correctlyYour website won’t resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address

Additional checklist for Drupal 7 sites

Disable page_compressionThe Compress cached pages pages option (page_compression) of Drupal 7 does not provide any benefit and might cause unexpected behavior when an external cache such as Varnish is employed.
Set the minimum cache lifetime to noneThe minimum cache lifetime prevents Drupal from clearing webpages and block caches for a period after the changes are made. If you set its value to greater than none, changes are not readily visible.
Ensure variable_set or cache_clear_all is not overusedOn a Drupal 7 website, excessive use of variable_set or cache_clear_all can cause flaws in caching and might create performance issues.
Enable Fast 404Processing 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.