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.
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 web page. 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.
- Create a Support ticket to help you find ways to optimize slow queries.
Am I accessing the file system as little as possible?
- Cloud Platform Enterprise uses a distributed file system. Although it is highly fault tolerant, we do see performance issues under conditions of frequent disk I/O. File system 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 Example one: Parsing a custom cookie.
- Add AJAX for dynamic elements on a static web page (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 web pages, but if high-traffic web pages still require greater memory limits after optimization, you may need added infrastructure, 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 Cloud Platform 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.phpfile using an HTTP request (also known as Poor man’s cron). Acquia’s documentation describes how to set up cron for Cloud Platform and for 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 Environment. You can use remote administration environments in whatever way you choose, or not at all. If you need custom environments, you can create a Support ticket to have the environments set up for you. Depending on how you want to use the remote administration environments, you may need added infrastructure.
Version control
Cloud Platform 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 Cloud Platform, note the following tips:
- Cloud Platform offers a feature known as Using the Live Development mode enabling you to change code directly on your infrastructure. 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 Cloud Platform’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 Cloud Platform, 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 Automation services.
Cloud API
The Cloud Platform API allows developers to extend, enhance, and customize Cloud Platform. Some customers use Cloud Platform 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 Cloud Platform API has three major components:
- A RESTful web interface allows direct control of Cloud Platform applications. Complete documentation for the Cloud Platform API web interface is available at Platform APIs.
- Cloud hooks are scripts in your code repository Cloud Platform executing on your behalf when a triggering action, including those triggered by Cloud Platform API functions, occurs. Complete documentation, templates, and sample scripts for cloud hooks are available from GitHub at Cloud Hooks.
The Cloud Platform API is available to all Cloud Platform customers. To get started with the Cloud Platform API, including information about your Cloud API credentials, Drush aliases, and Cloud Platform, see Developing with the Cloud Platform 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
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 Cloud Platform Cloud Platform. Some of the contributed modules invalidate caching by setting session cookies. Others break caching by setting
no-cacheheaders.
As you consider your caching strategy, keep the following in mind to ensure you are making the best use of Varnish, and 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 web pages 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 web page is static except for one, then loading one dynamic element using JavaScript can keep the rest of the web page 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. Infrastructure-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 Cloud Platform Cloud Platform. Acquia recommends catching incompatible modules before a large number of dependencies build upon them.