Though less tangible than workflows and presentation, giving attention to website performance is vital both during development and post-launch.  By scheduling time to establish parameters pre-launch and periodically checkingperformance post-launch, the chances of being caught flat-footed by unexpected traffic or bugs can be minimized.  As the old saying goes, “An ounce of prevention equals a pound of cure.”

Establishing Limits

During a project’s development phase, load testing should be done to establish how many concurrent users the site can handle without errors or slow page loads.

The first step is to dialogue with the client to get a rough idea of how much traffic should be expected. Then, tests can be done to confirm that expectations are realistic. Determining upper limits is essential because, post-launch, triggers can be defined that will alert stakeholders of unexpectedly high traffic.

Here are some tools to help with load testing:

  • Apache JMeter: JMeter is an open-source tool that allows concurrent user testing. The only limit to the load it can simulate is the available hardware.  It can also give feedback visually via charts and graphs.
  • NeoLoad: Though JMeter is powerful, if there is a need to delve more deeply into what may be causing problems, NeoLoad is a good alternative.  It can assist with checking DB performance and allows the use of multiple machines to simulate greater loads. NeoLoad also allows comparisons between tests.  

Client-side Performance 

It’s also vital to ensure great client-side performance. Being able to serve pages to a lot of concurrent users is great, but it’s pointless if users leave because page loads take too long.  A maximum acceptable load time should be established and tested against.  Here are some tips for reducing page load times:

  • Check for images that are too large: It may be possible to save large images at a slightly lower quality without an impact to the presentation.
  • Look for JavaScript errors or slow-running scripts: If JavaScript is causing a delay, it may be possible to defer its execution until the page is nearly finished loaded.
  • Aggregate JS and CSS: Drupal makes it easy to combine multiple JavaScript and CSS files to reduce the number of requests to the server with each page load.
  • Use image sprites: Another way to reduce the number of requests is to save multiple images as a single image known as a “sprite”.  Then, CSS can be used to display the appropriate parts of this sprite where they are needed.
  • FireBug: The FireBug browser tool can also be very helpful with seeing which page components are taking longest to load.

Monitoring Post-Launch

Being proactive about performance monitoring can make the difference between making granular changes in response to a trend of growing activity versus emergency hardware or configuration changes just to get a site back online.

So once some values and limits have been quantified, tools for performance monitoring must be selected and configured.  Here are some possibilities:

  • Performance Module: Tracks max and mean page load times, memory usage.  This uses memory_get_peak_usage() to monitor memory.
  • Zabbix client for Drupal: Zabbix is an open source monitoring system that can hook into Drupal via an associated module.  Zabbix not only monitors performance but also allows triggers to be set.
  • New Relic: New Relic is a performance monitoring service that can provide unlimited data retention, DB-level monitoring as well as a granular statistics specific to browser, page, or geography. This also provides module monitoring which can help identify any PHP bottlenecks.  Finally, New Relic can monitor front-end performance.
  • Droptor: This monitoring tool, free for use with a single site, is useful for monitoring multiple sites.  It has a series of checklists that run on your sites to identifies a variety of things like page-specific performance problems, modules needing upgrades, and security concerns.  It also has Drush integration.

Periodic Performance Reviews

Having performance monitoring with triggers is great, but it's also wise to proactively schedule periodic performance tests.  By proactively reviewing statistics, both before and after launch, potential problems can be identified before they have an impact on performance.  Also, this is a good time to apply patches to maintain security or perform module upgrades.

Do you have any suggestions for performance monitoring or load testing?  Let's discuss in the comments below!