HKDUG May meetup

Rah I'll be very interest but I'm not sure to be free this day.

Here's the short form of my talk on performance:

Terms

Peformance - How fast a web page takes to display.
Scalability - As your traffic increases does the performance stay consistent? How easy is it to keep things fast as your traffic grows?

The two are often related, but sometimes are in opposition. For example you can load your sidebars via AJAX, but doing so will increase the load on your server and thus decrease scalability.

Don't just randomly apply performance fixes/tweaks/modules/etc.

A doctor would never just start cutting. Diagnose your problem is before you start surgery. Also do a before and after test to make sure your "improvement" is actually helping. For some of these things a slight misconfiguration can make you worse off.

Optimization vs. Caching

These are the two main categories of performance improvements. Generally you can get small gains in optimizing what you already have (<50% improvement). But caching can often bring gains by an order of magnitude. The problem being that you can't always cache things (user-specific or time-specific data).

Automated performance suggestion tools

Things like mysqltuner2, YSlow, Page Speed, etc. Don't alter a setting until you understand how it works. Take the recommendations as only as suggestions - sometimes mysqltuner will tell you to keep increasing a variable when in reality it might actually make matters worse.

Authenticated Users vs. Anonymous Users

These are two separate cases and often need different optimizations. For anonymous users caching can go a long way. Boost is great even for shared hosting. Varnish (a reverse proxy) is even faster, but be prepared to spend some time tweaking it's config file. Varnish can even be useful for authenticated users.

Front End time vs. Query time vs. PHP time vs. Server configuration

Front End

• 85% of page load time is downloading images/CSS/JS and displaying/rendering/parsing/executing them. If page load time is your priority then focus on these things, not the time it takes to generate the HTML file.
• Reducing the number of HTTP requests is your #1 priority. And so CSS/JS aggregation and CSS sprites are very important. A great tool for CSS spriting is
  http://spriteme.org/
• Pull-origin CDNs are easy to implement and will allow you to tune your server as an application server rather than a combined application/static file server. See the Parallel module.
• YSlow is the defacto Front-End performance tool. Getting an A in YSlow will bring you to around 5 second page load time on an empty cache.
  http://developer.yahoo.com/yslow/
• Google Page Speed can then get you even faster.
  http://code.google.com/speed/page-speed/
• When doing jQuery, use $(window).load() for event binding rather than the $(document).ready() that you are used to. window.load fires after the page has finished rendering. This is a great place to put event binding so that it doesn't slow down the page load. No one will click on a button before they can see it.
• External stuff will really drag you down (Digg button, Add This button, Facebook Connect, ADVERTISMENTS!). Try to add these things after the page has finished loading via:
  
  $(window).load(function(){
  var head = $("head").first() || document.documentElement;
  var script = document.createElement('script');
  script.type = 'text/javascript';
  script.async = true;
  script.src = 'some_script.js';
  head.insertBefore(script, head.lastChild);
});
• Ad frameworks are almost all terrible. Most were written in the 90s and haven't been updated since. Even the big ones all suck. The only Ad framework that I've seen that performs well is BuySellAds.com
• Flash sucks. Not only in terms of performance.
• If you care about IE 6 or 7 you need to make your JS fast. When using jQuery don't use a class as a selector. Don't do this
  $('.some-class')...
  IDs are best.
  $('#some-id')...

Query Time

The database can be your Achilles Heel if you've got poorly built queries. Generally a query that takes longer than 1ms is a problem.

• The Block Cache is your best friend. Cache as much as possible. You can use Blockcache Alter module to setup block caching on sites that use node access control.
• Enable caching for Views blocks. By default Views blocks are not cached because Views can't tell if you are building a list only for admins, or what. This can help a lot on a Views heavy site.
• Use the Devel module to see all the queries that are run to render a page. Know that this does not include Views queries. You need to turn that on seperately in Views tools tab.
• Find identical queries that are run multiple times on a page. These are candidates for a PHP static variable.
• Find the longest running queries. Use EXPLAIN to see how the database is executing them. Is the database able to utilize indexes?
• Your views queries are often in need of indexes. Use DB Tuner module to find what fields need indexes.
• Use mytop on a running site to see what queries are being run in real time. If things are backing up you'll be able to see what the problem query is here.
• Enable the slow query log (slow query time of 1sec). Regularly (maybe once a quarter) analyze the log to see what queries are slow.

PHP time

Page generation time - query time = PHP time.

• Watch out for external things (sending email, connecting to an external server, etc.). Use Job Queue module to send the expensive stuff to cron.
• You can use xdebug to generate cachegrind files. You can analyze these in a tool like webgrind or KCacheGrind. These analysis tools will show you what functions/methods were called to generate the page, how many times they were called and what percentage of the total time they took. This is a good way to find that misbehaving recursive function that is getting executed 80,000 times per page load.
• make sure that you have a PHP opcode cache running so that your code doesn't have to be recompiled on every page load. APC is great

Server Configuration

This is a talk for another day.

Other measurement Tools

Apache Bench - great for doing a quick and easy before-and-after test. Only measures the time to generate the HTML document, does not include CSS/JS/images etc.
JMeter - good for more advanced testing - simulating several different users traversing different paths through your site.

Drupal specific stuff

• Pressflow - a performance optimized version of Drupal. MySQL only. Includes several back-ports of Drupal 7 patches. Required if you want to use a reverse proxy.
• Block visibility. All blocks are rendered on all pages unless you are using block visibility rules. If for example a block is in a region that is only printed on the front page, that block is still being built on every other page, just not shown. Restrict the block visibility to just the front page and then you're golden.

I think that's most everything that I covered.

Thanks Dave ! It will be really useful for me too :).