performance

Here's a quick tip for people running multiple Drupal instances on one server: don't run cron for all sites on the same moment but try to spread it.

Suppose I have 5 sites: site1.tld, site2.tld, ... and I want to run cron each 12 hours. I would enter the following using crontab:

Packt Publishing is on a roll. They have been releasing a few Drupal books recently on a broad variety of topics. We have seen books on Social Networking with Drupal, JavaScript and jQuery, multimedia, ...

Last week they have released a new book focusing on performance and maintenance, called Drupal 6 Performance Tips. Although the title focusses on the performance topic, a lot of tips are also provided for maintaining or developing your site.

Creating pretty urls or permanent links in Drupal is easy. Really easy. This functionality comes out of the box with the Path module. And by adding the contributed Pathauto module you can make your life easier by letting Drupal generate the pretty urls automatically based on some properties of your post (like the title).

But there's another way of doing this in Drupal. Drupal provides a mechanism in code by means of the custom_url_rewrite_inbound and custom_url_rewrite_outbound functions. Using these wisely may give you some performance gain. Let's see how you can use these.

This is a quick tip for people running scripts (or cron) with a lot of node_load.

If you call node_load, it does some static caching keeping the node object for the duration of the script to save some calls to the database.

<?php
function node_load($param = array(), $revision = NULL, $reset = NULL) {
  static $nodes = array();

  if ($reset) {
    $nodes = array();
  }

  // loading the node...

  return $node;
}
?>

If you have a lot of those node_load calls, this needs a lot of memory. Megabytes.

But node_load was built with a reset option. So if you run it with the $reset parameter set to TRUE, it will clear its static cache. And your code is no memory hog anymore.

Every serious Drupal developer has heard of the Devel module. This little devil can do a lot of things like being a firefug for Drupal theming, content generation, ... But one of it's most interesting features is the displaying of queries run during a page request. Excellent performance monitoring tool while debugging!

But did you know that the monitoring of queries is built right into Drupal? Devel just builds upon it.

You can activate this feature by setting the variable dev_query to 1. As there's no interface to do this, the quickest way is to set the $conf array in settings.php.

$conf['dev_query'] = 1;

When this variable is set to one, all queries issued via db_query and it's brothers and sisters like db_query_range, pager_query are gathered in a global variable $queries. Global variables can be accessed anywhere by declaring the variable as global (again).

function test() {
  global $queries;
  print_r($queries);
}

And there you have it! All queries are printed out using print_r.

The best moment to see which queries were run is of course at the end of the request. In Drupal this is possible using hook_exit. But other modules might still issue some queries there (like the statistics module). If we wanna catch those too, it's best to use a PHP core function: register_shutdown_function. Using this function you can register another function that should be run after all other code has been run. A good moment to register this function is during hook_init.

function my_module_init() {
  register_shutdown_function('display_queries');
}

function display_queries() {
  global $queries;
  print '<pre>';
  print_r($queries);
  print '</pre>';
}