Tags
black swan business caching cdn Collaboration Content Management customer underground daas dbpedia ddu ddu2012 drupal Drupal Uriverse DBpedia Solr facebook gpl hosting location mailchimp mapping mercury mobile modules multisite PayPa performance plugin pressflow progressive enhancement Publishing randomness ratings rdfa responsive web design reviews saas scalability semanticweb Social Subscription themes topicmaps uriverse wikipedia wordle wordpress
Drupal Performance Out of the Box (part 5)
Drupal has a number of features which allow for performance to be improved without the addition of external modules or for complicated configuration by administrators. A slow system can easily be turned into one which performs well under heavy loads.
Firstly, Drupal shortcuts the execution of unneeded code by using an internal caching system which stores results of expensive routines. Secondly, Drupal improves page rendering time by allowing for the aggregation static JS and CSS files. Thirdly, page output can be compressed saving download time. Fourthly, Drupal allows for manual configuration of the caching of Blocks and Pages which can improve performance significantly.
Drupal Core caching system
Drupal comes with a number of in-built caches which store the results of expensive calculations (strings) in the database so that they can be retrieved quickly later on. There are six caches enabled by default: cache, cache_block, cache_menu, cache_filter, cache_form and cache_page. Contributed modules are able to create their own caches for storing data which is handy for module designers. This default cache system provides improved performance across the whole app.
The caching system is pluggable and allows for custom storage engines to be substituted in for the default database implementation. Later in this guide you will see how the Cache Router module is able to swap in memory based storage in place of the database, making the retrieval of cached content that much faster.
All sites: Improved performance across the app. No config.
Aggregate and compress JS and CSS
Drupal’s modular system means that pages can have a large number of CSS and JS includes which results in a lot of client server communication – slowing the page draw time down. The problem can be alleviated by merging the files and then compressing them. This results in less includes and faster downloads. Up to 90% of download time can be attributed to downloading CSS, JS and images so it makes sense to aggregate and compress if possible.
During development it is advisable to keep this option turned off so that CSS and JS errors can be troubleshooted.
All users: Lower render times. One click config.
Page Cache for anonymous users
Pages for anonymous users can be cached, meaning that a full build of the page isn’t necessary for each new request which comes in, providing you with savings in CPU and DB load as well as giving the user much faster response times. This is a massive win for your website, especially if the majority of your page requests are from anonymous users. Basically it can help you survive a Slashdotting. Drupal offers “aggressive” and “normal” options – normal page caching is recommended for most websites. Other options for Page Caching are discussed below.
During development it is advisable to keep this option turned off so that any changes to logic or design can be troubleshooted.
Anonymous users: Big wins in speed and CPU. One click config.
Block Cache
Enabling the block cache allows finer grained control over cached content. Caching blocks which don’t change frequently will enable speedups for logged in users who need a dynamic page built for them each request.
Logged in users: Moderate wins. Easy to implement.
Page Compression
It is also possible to enable page compression for the pages sent. This will reduce the page size by 50% or more depending on the page. Users requesting big pages on slower connections will love this.
Slow connections: Massive win. Easy to implement.
This article forms part of a series on Drupal performance and scalability. The first article in the series is Squeezing the last drop from Drupal: Performance and Scalability.