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.
| 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 |
| □ | Enable & configure Acquia Purge module | Acquia 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 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 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 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 |
| □ | 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 |
| □ | 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 |
| □ | 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 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 |
Additional checklist for Drupal 7 sites
| Task | Why | |
|---|---|---|
| □ | Disable page_compression | The 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 none | The 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 overused | On 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 404 | 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. |