Information for: DEVELOPERS   PARTNERS

Best practices for developing on Acquia Cloud

Acquia provides a plethora of tools and documentation aimed at enabling developers to write and manage scalable and maintainable code. We recommend you start with the following best practices and familiarize yourself with the following tools and concepts.

Lightning Best Practices Banner

Coding standards and best practices

Good coding hygiene is a broad subject. In our experience, the following recommendations address the most common coding issues we see.

Follow Drupal.org coding standards

Ensure you understand and adhere to Drupal coding standards documented on Drupal.org’s Coding standards webpage. The Coder module can help you conduct internal code reviews against the documented standards.

Avoid modifying Drupal core files

Changing Drupal’s core files makes your application difficult to maintain because you must keep track of and reapply your changes as you apply security and other updates. Remote Administration does not cover modified core or contributed modules, so Acquia recommends you add any customizations with custom modules or theming files. The process allows the Remote Administration team to add updates, while allowing the client development team to change custom code without any modification loss.

If your application requires Drupal core or contributed module modification, refer to Patching and locking modules for details on how to patch or lock modified modules properly to ensure your application remains compatible with Acquia security updates.

For a more in-depth discussion of why altering Drupal core files can be problematic, see Never hack core.

Write scalable and maintainable code

Consider how your architecture and supporting code will scale. Although we cannot mention everything you should do and everything you should avoid, consider the following questions:

Are my database queries performant?

  • Avoid creating views with a large number of relationships. A large number of relationships generate queries with lots of joins, which can cause an undue load on the database. We recommend you simplify complex views, using views caching, or write an optimized query as a custom module.
  • Use New Relic to identify slow queries. We can provide you with a copy of the slow query log for your environments.
  • Contact Acquia Support to help you find ways to optimize slow queries.

Am I accessing the file system as little as possible?

  • Acquia Cloud Enterprise uses the Gluster distributed file system. Although Gluster is highly fault tolerant, we do see performance issues under conditions of frequent disk I/O. Gluster performance can become degraded when handling more than 1000 files in a single directory. The extent of the degradation depends on the size of the files in question.
  • We recommend you consider ways to reduce the number of files in a single directory, or add a CDN or a third-party file serving service such as Amazon S3. For more details, see:

Is my application as cacheable as it can be?

  • Avoid setting Drupal session cookies (Drupal’s SESS* cookies contain Drupal session information) for anonymous users. For more information, see Session cookies invalidate Varnish caching.
  • Avoid varying content based on HTTP headers or cookie values. For more information, see Varying Varnish caching by cookie value.
  • Add AJAX for dynamic elements on a static webpage (for example, the cart button on a product catalog).

Is my memory footprint as small as possible?

  • Avoid using PHP memory-limit overrides. Use memory profiler, XHProf, and New Relic to identify memory leaks and processing bottlenecks.
  • You may consider conditional memory overrides on select administrative webpages, but if high-traffic webpages still require greater memory limits after optimization, you may need added hardware, for an added cost.

Am I avoiding unnecessary HTTP requests?

  • Calling external services inline (for example, in PHP using drupal_http_request()) can hang PHP processes, causing Acquia Cloud to display HTTP 503 status codes under load. External calls should use either AJAX or a Drush job executed by cron.
  • Avoid executing Drupal’s cron.php file using an HTTP request (also known as Poor man’s cron). Acquia’s documentation describes how to set up cron for Acquia Cloud and for Acquia Cloud Site Factory.

Workflow

Acquia’s network tools encode best deployment practices. We give you development, stage, and production environments for building, testing, and deploying your code. Remote Administration customers will also see a Remote Administration environment. You can use remote administration environments in whatever way you choose, or not at all. If you need custom environments, you can contact Acquia support to have the environments set up for you. Depending on how you want to use the remote administration environments, you may need added hardware.

Version control

Acquia Cloud uses the Git version control system to manage your application’s code. Git is an industry standard technology allowing you to manage and track changes to your application’s code. Basic documentation on using Git is available from Resources for learning Git. For using version control on Acquia Cloud, note the following tips:

  • Acquia Cloud offers a feature known as Using Live Development mode to change code on your server enabling you to change code directly on your servers. The Live Development feature is useful for making quick changes. Acquia recommends not using Live Development as your primary development workflow, because the feature prevents you from taking advantage of some of Acquia Cloud’s features, and could cause problems with keeping your repository in a consistent state.
  • Do not commit large files into your Git repository. Large files can cause your repository to balloon in size, potentially causing problems deploying even small code changes. Most binary files (for example, documents, images, and videos) belong in Drupal’s public files directory, which is not part of your repository. If you do commit large files to your repository, note they cannot be removed by deleting them, since the large files will remain in your repository’s history.
  • Ensure you deploy to tags, not branches.

Drush

Drush is a command-line tool executing Drupal code without accessing the Drupal web interface. To use Drush with Acquia Cloud, you can set up an aliases file to execute commands against your Acquia application locally, or you can SSH into your environment and execute Drush commands anywhere within your application’s docroot directory. Drush aliases are explained in more detail in Using Drush aliases.

If Drush is not functional on your application (for example, errors prevent Drush commands from completing), your application will not receive automated updates through Acquia’s Remote Administration automation services.

Cloud API

The Acquia Cloud API allows developers to extend, enhance, and customize Acquia Cloud. Some customers use Acquia Cloud API to integrate with third-party command-line tools, such as Jenkins, to build automated testing and other QA and acceptance steps into Acquia’s development/stage/production workflow.

The Acquia Cloud API has three major components:

  • A RESTful web interface allows direct control of Acquia Cloud applications. Complete documentation for the Acquia Cloud API web interface is available at Acquia Platform APIs.
  • Cloud hooks are scripts in your code repository Acquia Cloud executing on your behalf when a triggering action, including those triggered by Acquia Cloud API functions, occurs. Complete documentation, templates, and sample scripts for cloud hooks are available from GitHub at https://github.com/acquia/cloud-hooks.

The Acquia Cloud API is available to all Acquia Cloud customers. To get started with the Acquia Cloud API, including information about your Cloud API credentials, Drush aliases, and Acquia Cloud, see Developing with the Cloud API.

Cloud hooks

Cloud hooks provide a mechanism for systematically executing scripts in response to certain platform events, such as code deployments. For example, you can set up a script to perform database updates routinely, and do feature reversions whenever new code is pushed to a tag. For more information on how to set up cloud hooks, see Automating with Cloud Hooks.

Caching

The Acquia Cloud platform uses Varnish® for caching. All Acquia load balancers, whether shared or dedicated, have Varnish running and serving traffic. Certain conditions can prevent Varnish from caching requests:

  • If your application sets a session cookie for anonymous users, Varnish does not cache requests. A common example is setting session cookies to track a visitor through the application. If you enable the display of messages, Drupal sets a session cookie to prevent caching of anonymous traffic. Although setting a session cookie makes sense for development, session cookies should not be used with production websites.
  • Several contributed modules can invalidate Varnish caching, described in Modules and applications incompatible with Acquia Cloud Acquia Cloud. Some of the contributed modules invalidate caching by setting session cookies. Others break caching by setting no-cache headers.

As you consider your caching strategy, keep the following in mind to ensure you are making the best use of Varnish, as well as Drupal’s own internal caching mechanisms:

  • Ensure your build includes the basic set of modules for enabling selective purging of Varnish cache:
  • Setting cache headers on webpages may require a lower cache lifetime (for example, your homepage). See Bypassing Varnish cache for more information.
  • Consider loading dynamic elements asynchronously. If every element on your webpage is static except for one, then loading one dynamic element using JavaScript can keep the rest of the webpage cacheable.
  • Check Varnish for optimal caching before load and performance testing.
  • You can prevent Varnish from caching in your development environment, so your developers can consider changes. See Disabling caching and aggregation in non-production environments for more information.
  • Avoid varying content based on cookie and header values. The process is common with websites enabling users to set language preferences, or wanting to serve different content to users in different countries. Ideally, all content variances are addressed on the URL, and are compatible with caching. If content variances are incompatible with caching, you must engage Acquia to create a custom Varnish configuration.
  • Create an adaptive or responsive theme. Server-side device detection is incompatible with Varnish caching.

Incompatible modules

Ensure you check your build against Acquia’s list of incompatible modules. A list of those modules is available at Modules and applications incompatible with Acquia Cloud Acquia Cloud. Acquia recommends catching incompatible modules before a large number of dependencies build upon them.