Scaling WordPress

WordPress is powering some of the biggest publishing sites on the web (CNN.com, techcrunch.com, wired.com). It's no accident that one of best CMSes on the web is chosen to be the publishing platform of choice by these content providers. That said, each of these companies have had to work hard to push the limits of the software to scale to meet the needs of their enormous audiences. In my talk, I will discuss the essential ingredients needed for scaling WordPress to millions of users. This talk will include discussion of integrating external services and technologies along with performant PHP practices to provide a stable publishing experience for the masses.

Joind.in Page –Slides

by Zack Tollman @tollmanz

I came to this talk from the perspective of a plugin developer rather than a site maintainer so not all of the content was completely applicable to me. However, there were a few bits of information about WordPress that I found very useful and I walked away with affirmation that the approach we have been taking in our plugin is a good one from a scalability perspective. Overall Zack was a good presenter and had a well composed slide deck. I would attend another talk by Zack.

My notes for this talk can be found below:

  • page caching – turn wordpress into a static site, mic drop
  • caching reduces site load
  • page caching – batcache, varnish
  • edge caching – a service, cdn, fastly, cloud flare
  • low TTL to avild invalidation pains – 5 mins is a good compromise
  • diagnose issues in the code that might be contributing to bad performance
  • use your experience and tools
  • database queries are most likely the bottle neck – especially with poorly written plugins
  • remote requests can create a lot of latency – especially if the remote server is slow
  • slow methods – looping/recursion
  • WP plugin: Query Monitor – has section for “slow queries” greater than 100ms
  • XHProf/XDebug – if you have access to the server
  • New Relic – service
  • Treat with object caching – WP_Object_Cache class, wp_cache_set, wp_cache_get
  • object caching analogy – grocery shopping
  • write your own WP_Object_Cache for better performance – memcached, apc (not meant for this)
  • use transient API if you are a plugin or theme developer and don’t have control of the server
  • transient API will use the WP_Object_Cache
  • proactive approach – only cache events that will be reused opposed to caching the entire page
  • proactive approach – update cached content via scheduled events
  • stale while revalidate – if a user request old data serve it to them but initiation a background process to update the old data
  • prevent scaling issues with a solid stack
  • edge network -> load balancer -> page caching -> web server -> persistence layer and object cache
  • separate admin traffic from public traffic
  • object cache + page cache = happy life
  • http://tollmanz.com/mwphp15
  • from wired