It is well known that Drupal can be a hog with server resources. What is not common knowledge is that high performance Drupal is a magic art that can only be done by wizard elves during the hours of midnight and 6am every other Thursday while the moonlight shines down from the north side of the sky. With recent developments in high performance Drupal hosting based on the Pantheon stack, we are quickly taking this black art and making it easier for the common man to have a Drupal site that scales and runs fast without any knowledge of wizardry and black arts.
Not all that glitters is gold
One of the largest problems we face for Drupal sites is that this high speed hosting only affects about 80-90% of your site visitors. The power of Varnish is that anonymous users get a high speed site, but authenticated users including the site administrators or anyone with an account will still face scaling issues on an untuned site. Part of our services here at Chapter Three is to provide high performance consulting for sites that are running slow. We use common tools to analyze the data and optimize the Drupal application stack.
What we will learn
In this 3 part series of blog posts, I will show you how to:
- Install and configure Xdebug
- Profiling your Drupal application with Xdebug
- Trace and visualize the execution flow
- Benchmark the performance improvements
The first step is getting Xdebug installed. This can have various levels of difficulty depending on your operating system. I use OS X and Linux primarily and typically like compiling things myself, but the Xdebug site hosts compiled DLL files for download that you can use to get this going on a Windows based computer.
Installing on Unix/Linux
The easiest way to install Xdebug on a Unix based operating system (ie. Linux or Mac) is to use PECL.
~ steverude$ sudo pecl install xdebug
Installing on Windows
The easiest way to install Xdebug on a Windows based OS (very uncommon) is to download a precompiled binary from xdebug.org.
Configuring and activating Xdebug
To configure Xdebug, you need to enable the trigger that allows you to execute Xdebug profiling. There are two ways to do this. The first is to allow Xdebug to run profiling on every page load by setting xdebug.profile_enable=1 to the ini file for PHP. The downside to this is that this adds a considerable amount of overhead to each request. The preferred method is to set the trigger to allow you to trigger profiling on demand. The last thing you need to do is tell Xdebug where to output the cachegrind files in order to analyze these files later. The configuration options for setting this up in your php.ini file are as follows:
zend_extension=/usr/lib/php5/20090626/xdebug.so xdebug.profiler_enable_trigger = 1 xdebug.profiler_output_dir = "/tmp"
Or on Windows you need to add:
zend_extension_ts="c:\php\ext\php_xdebug-2.0.1-5.2.1.dllphp_xdebug-2.1.1-5.2-vc6.dll xdebug.profiler_enable_trigger = 1 xdebug.profiler_output_dir = "/tmp"
Now when you browse to your site, you can add "XDEBUG_PROFILE=1" to the query string and it will trigger an Xdebug profiling session and output the cachegrind file.
In the upcoming blogs in this series, we will show you how to analyze the profiling data in the cachegrind file and how to optimize the site using this data.