Scaling the guardian

Scaling the Guardian Michael Brunton-Spall (@bruntonspall) michael.brunton-spall@guardian.co.uk

The Guardian - Some Figures ABCe Audited (Dec 2009) Unique Users - 36.9m per month, 1.8m per day Page Impressions - 259m per month, 9.2m per day Log file analysis 37m requests per day, 1.1bn requests per month - not inlcuding images / static files

Initial Architecture

Scaling Problems In memory cache is order of magnitude too small at 500Mb

Even Worse! Cache is local to appserver Adding an App Server makes the problem worse

Our Solution Memcached! or more accurately, a distributed cache

Our Solution

Phase 1 Memcache object cache Massive reduction in number of DB calls No significant drop in DB Load

Phase 2 Memcached query cache Massive reduction in DB Load

Phase 3

Phase 3 Memcached pages More reduction in Appserver load Must handle customisation outside of cache Memcached for pages is filter Page customisation is a higher filter Time based decache only Decache only on direct page edit

Getting a Scaling Solution The problem isn't technical It's all about the process Agile doesn't scale well! Onsite customer doesn't care about scaling Dedicated 10% team to look at "platform" issues Still Agile, Customer is Operations Team & Architects (backend and frontend)

Scaling small apps rapidly On Thursday 15th 2010 there was a historic UK event - a televised national debate.

Poll Charts Always sounds simple: "Let people viewing the page vote at anytime whether they like or dislike what the party leader is saying. Oh, and lets show it with a real time graph" Bad words here anytime real-time graph

Our coverage looked like this...

The poll itself

The poll itself Python Google App Engine An inhouse, inplatform cache

The Naive Implementation class IncrLibDemRequest: def get(self): Poll.get().libdems += 1 Why? Google App Engine has transaction locks, simultaneous threads can't atomically increment a counter (duh) If you wrap in a txn, all threads are serialised. You just turned Googles massively parallel data center into a very expensive file backed db

Our Implementation (Phase 1) Sharded counters are the way to go Follow the article at code.google.com/appengine on sharded counters Gives parallel counters But beware....

Our Results and Numbers

Some interesting notes Average of around 100-120 req/s Peaked at 400 req/s Total of nearly 1,000,000 requests Surprisingly little cheating Only 2000 requests But...

Request Duration Between 1 sec and 8 seconds! Causes Thread contention Not enough shards

Our Implementation (2) Increase shards by factor of 10? Completely reduces transaction failures Each request still takes 200ms The cost is the datastore write Replace datastore with memcache? Different architecture vote does memcache atomic increment/decrement results get from memcache cronjob 1/min reads from memcache and writes to datastore requests now take 20 ms

The Results?

Some notes Total of around 2,727,000 requests Average of around 454 req/s Peaked at 750 req/s

Requests per Second But...

Request Duration Average 1.2s at first Live deploy fixed to 300ms

Any Questions? Michael Brunton-Spall (@bruntonspall) michael.brunton-spall@guardian.co.uk

http://lanyrd.com	15
http://www.slideshare.net	8
http://coderwall.com	2

Scaling the guardian

by Michael Brunton-Spall

Accessibility

Upload Details

Usage Rights

3 Embeds 25

Statistics

Scaling the guardian Presentation Transcript