performance archive

Drupal 7 includes a big re-factor of the way CSS and Javascript are aggregated. What does this mean for your sites? In short: You will see a greater number of files compared to D6 - this is normal and not usually cause for alarm. Surprisingly, more files is sometimes better. To ensure efficient aggregation, the most important thing developers can do is choose the parameters to drupal_add_css and drupal_add_js carefully. And if you encounter contrib modules that are using the wrong parameters, please file patches! This was a somewhat controversial change, and understanding the new strategy (and how to override it) requires going a bit deeper. Read More…

Drupal generates nicely styled 404 pages that are easy to customize. And since 404 responses can be served from the page cache, the performance hit from the occasional stray image can be minimal. However, if you're embedding 3rd-party content (such as ads or social widgets), there is an additional risk that a misbehaving app can generate bogus requests with random-ish query strings. The unpredictable URLs will totally defeat the page cache, so on a really busy site the added load can be crushing. Read More…

If you've ever used JMeter, you know it's an awesome load testing tool. It also comes with a built-in graph listener, which allows you to watch JMeter do, well... something. While this gives a basic view of response time and throughput, it doesn't show failures, nor how the server responds as load increases. And let's face it, it's just plain ugly. Enter Matplotlib, a beautiful (though complex) plotting tool written in Python. Read More…

In the discussion following my last post about cron and the cache hit rate, I promised to do some testing of the different cacherouter backends, as well as Boost. Again, these tests focus on the needs of a smallish site with 500 nodes and 1200 requests per day. Boost is the clear winner for response time (which shouldn't be a surprise given that it allows the web server to deliver HTML files directly from disk). Read More…

A lot of what's written about performance tuning for Drupal is focused on large sites, and benchmarking is often done by requesting the same page over and over in an attempt to maximize the number of requests per second (à la ab). Unfortunately, this differs from the real world in two key ways: Read More…