In my last post, I wrote about the cost of tech debt, using a case study of skyrocketing hardware costs. Here's another, subtler effect of poor performance: impatient customers don't stick around when they experience slowdowns. However, choosing to prioritize speed can be hard to justify when the cost isn't quantified.
Welcome to the first part of a two part article on a terrible way to use node references, how it was fixed, and the troubles implementing the solution. In this post, I'll provide some background on the problem encountered and talk briefly about the proposed solution.
If you are using New Relic for performance monitoring a Drupal project, you may have noticed a large discrepency between the browser throughput and app server throughput. In the example that follows, the difference is 100:1. The cause is a limitation in the auto-instrument feature:
At tonight's PDX WordPress Dev meetup (thanks for the pizza Digital Trends) Daniel Bachhuber had some questions about benchmarking a plugin. Benchmarking WordPress itself is easy, but it's harder to isolate a specific plugin, much less a few calls to preg_match_all() within it. The questioned SEO Auto Linker plugin does this on every page load, so any running time adds latency on every page.
Speculation from the meetup is that a PHP regex operating on post content, a blob, and looping through hundreds of links could be pretty slow. Too much caffeine today meant I had to give it a try.
We like to use our own site to experiment with different technologies. CDN's are nothing new, and Metal Toad has projects running on competing systems including Akamai and Level 3. Still, I think Amazon Cloudfront is an interesting offering and I wanted to give it a spin. Here's my review of the service after setting it up with Drupal:
Our responsive redesign has been a great improvement for metaltoad.com. I was still not entirely satisfied with the speed of our site, especially while waiting for my train at the busy Pioneer Square! One of the major obstacles for mobile networks is lag, and so I set out to cut down the number of HTTP requests. By improving the site's stylesheets and scripts, I was able to eliminate a dozen extra requests.
- 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_jscarefully. 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.
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.
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.