1.Correctly configure Block Visibility settings
Drupal's block system allows you to place content in specific theme regions. But beware: even if you do not output a block in your theme, it will still be generated by the Drupal stack! That's because any enabled block's generation is determined by the block's visibility settings, not by the theme's region output. For example, if you have a page.tpl.php file and a custom page-front.tpl.php file with a custom $myregion for the frontpage where you output a complex block, then this block is also generated on every other page.tpl.php page! Even if you don't output the $myregion in page.tpl.php, the block is still generated based on its visibility settings. To solve this problem, dive into your blocks' settings and correctly configure the block visibility settings. If you only want to show a block on the homepage, then enter
Advantages
* Avoid unnecessary block generations on pages you do not output the block's region
2.Disable the statistics module
Drupal's statistics module has a disadvantage: extra MySQL queries per page load. Even when using the Boost module, boost_stats.php can still call these MySQL queries. Of course, it is up to you whether you need these Drupal stats. Most people will use Google Analytics as an alternative.
Other alternatives are server tools like Munin or Cacti.
Advantage
* Reduce MySQL requests per page
Disadvantage
* Live without drupal stats; install Google Analytics
References:
Download Google Analytics (module)
3.Enable core caching features
Often overlooked by Drupal beginners, but still worth mentioning: do not forget to enable core caching at Administer > Site Configuration > Performance (/admin/settings/performance). To avoid issues with Drupal modules, simply select Cache Mode: Normal. And enable Page Compression.
Here you can also enable bandwidth optimizations and block cache. We will come back to that later.
References:
Drupal caching, speed and performance
Caching modules that make Drupal scale
4.Enable native module caches (e.g. Views, Panels, Feeds)
Several Drupal modules bring their own caching system and caching tables. For example: Views, Panels and SWF Tools. Each have their own configuration options. On production servers, it is wise to enable them.
Views Cache
The Views module cache is hidden as an option on the Edit View page: Caching... And lets you choose cache by time for query results and rendered output. I usually select the same time length for both. The Views module is content-unaware, but there is a module for that: Views Content Cache.
5.Install ImageCache to generate thumbnails
ImageCache is a module that can generate image thumbnails on the fly, to exactly fit your dimensions. The thumbnails is only generate once, so should not influence performance. The benefit however is to the end user: visitors will download smaller images instead of the full unscaled version.
In the earlier days of the internet often people would upload huge images scaled by setting HTML width and height. Images looked small, but took ages to download. ImageCache fixed this problem. Use ImageCache in combination with various tools, including inside node.tpl.php and page.tpl.php.
Advantages
* Smaller images, reduced bandwidth
* Allows extra compression options
References:
Download ImageCache (module)
ImageCache and Lighttpd
6.Increase minimum cache lifetime on high traffic sites
Drupal's core caching system allows to set minimum cache lifetimes. This means content will not be refreshed until after a certain time. For example, on busy sites, you would set the Minimum Cache Life to 1 hour. That means visitors do not see changes on your site more often than 1 hour. But it greatly helps to improve cache-efficiency and reduces your server load.
Advantages
* Improved cache-efficiency
* Reduced server load
Disadvantages
* Vistors see less frequent content changes
7.Install the CSS Gzip module
Install the CSS Gzip module
Drupal handles separate CSS files per module. This way module maintainers can provide their custom CSS. But the disadvantage is you get a lot of CSS files. Each file requires a separate HTTP request. The CSS Gzip module extends Drupal's core CSS handling.
Drupal can automatically optimize external resources like CSS and JavaScript, which can reduce both the size and number of requests made to your website. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times.
Advantages
* Faster than mod_deflate
* Faster user-end load times
Disadvantages
* Requires clean URLs to be enabled
* Requires public download method
References:
Download CSS Gzip
8.Install the DB Maintenance module
The DB maintenance module periodically optimizes your MySQL database tables. It runs the SQL statements OPTIMIZE to make sure the integrity of your tables is kept sane.
Advantages
* Avoid table corruption, optimize database table structures
* Faster table access
9.Install the Javascript Aggregator module
Drupal 6.x has a built-in JavaScript compression tool at Administer > Site Configuration > Performance, near Bandwith Optimizations. However, end-user performance can be taken one step further by minifying that file. The Drupal JavaScript Aggregator module provides that option. Files are minified once, and refreshed when needed.
Advantages
* Minifies the JavaScript files before compression
* Reduces end-user load times and server bandwidth
References:
Download Javascript Aggregator
JSMin, the JavaScript minifier
10.Install the Update Status Advanced Settings module
I recommend turning the Update Status module on for production servers. It informs you when to update critical security patches. But the core module does not let you control how often should be checked for updates.
Enter the Update status advanced settings module. This lets you check once per day, or once per week, and also lets you disable checking for specific modules.
Advantages
* Check for module updates less frequently, i.e. only once per day or week
References:
Download Update Status Advanced Settings (module)
11.Uninstall unnecessary Drupal modules
Does it really matter how many modules you run? According to 2Bits more modules means more RAM and CPU usage. Each time the Drupal stack is fired it needs to read all module files. Adding more modules means:
* Higher CPU usage;
* Higher RAM usage;
* More opportunity for bugs to slup in;
* More (MySQL) database hits;
* Higher chance of a module with slow database queries;
* More maintenance!
All of them are good reasons to avoid an open buffet of Drupal modules. Only use what you need.
Advantages
* Free up server, PHP, MySQL and Drupal resources
References:
2Bits: Drupal modules: Less is more
12.Avoid calls to node_load() where possible, use fields
Drupal's node_load() function fires a great deal of queries and functions. The more module you use, the more node hooks will be involved in this call. Wherever possible it is advised to avoid calls to node_load(). Instead, try to fetch the specific fields you need directly. Best example: Views. Using the Views module you can build a page that lists all nodes. Each item requires a node_load() call. To avoid this, switch to using Fields in Views instead and call the fields that you really need. Then use custom Views theming to output the data.
Advantages
* Reduce the load on the Drupal stack
Disadvantages
* Requires more work, more fore-thought of what you need
References:
Drupal API: node_load()
13.Avoid calls to taxonomy_get_tree()
Drupal's taxonomy system, to categorize and tag content, has one bad function taxonomy_get_tree(). It works fine on small sites with few tags. But on large sites with over tens of thousands of taxonomy terms, you should avoid it at all cost. The function namely stores all terms into the PHP RAM memory, quickly blocking further PHP execution.
Drupal core uses the function on several pages, such as the admin/content/node page and others. A solution is to use the Views Bulk Operations module (VBO) to replace that page with a custom view.
Advantages
* Free PHP memory consumption by avoiding heavy taxonomy_get_tree() calls
References:
Download Views Bulk Operations (module)
Drupal API: taxonomy_get_tree()
14.Avoid using the PHP input filter
Drupal provides a PHP input filter out of the box. It lets you use custom PHP inside nodes and blocks. The downside is that this PHP code is stored in the database. Upon a new page request this code must be retrieved from the database and executed through PHP's eval() function.
But the biggest drawback is this: the PHP input filter is not cached. The solution is to write a custom Drupal module to do the task.
Advantages
* Custom modules are cached, PHP input filter is not
Disadvantages
* You must learn to write your custom Drupal modules (but it's really fun!)
Really great post, Thank you for sharing this knowledge. Excellently written article, if only all bloggers offered the same level of content as you, the internet would be a much better place. Increase business performance. Please keep it up.
ReplyDelete