asynchronous personalization[and CDNs and A/B testing and stuff]

Jon PliskePerformance Engineering, Groupon

@jonpliskejpliske@groupon.com

Jon PliskePerformance Engineering, Groupon

@jonpliskejpliske@groupon.com

You might know me from this leaked photo on TechCrunch

overview

backgroundCDN cachingasync personalizationa/b/multivariate testing /w finch.js

performance anxiety

big rails appbig teambig traffic

performance issuesdevelopment process hurdlesdrinking problems

===

Reaching limit of Rails' cachingLow-level optimizations too "incremental"Rewriting SQL is boringImprove platform architecture

super bowl party

prelude:jan 1. "btw we have pre/post super bowl commercials"jan 15. "scored an in-game spot, we good?"feb 15. offend the world

"spike mode":CDN cache it all!disable loginoffload geocoding/subscriptions/orders to EC2limited functionality === unhappy users

pics or it didn't happen

pics or it didn't happen

CDNs are neatproslow latency"edge side nodes"high capacitystatic content

consdynamic contentpersonalizationcomplexityoverkill?

specifically:personalized content (login menu, deals)analytics trackinga/b testingRails developers

async personalizationtarget: deal/division pages (> 50% of traffic)

approach:1. cache "anonymous" page in CDN2. hide stuff3. make AJAX request for personalized data/content4. show stuff

See Chris Williams' "Rails’ Best Caching Method is JavaScript"from GoRuCo 2010

obligatory omnigraffle diagram

"Anonymous" userbefore:initial page response time: 0.8 sec rendering time (e.g. loading css/js/images): 1 sec total: 1.8 sec

after:initial page response time: 0.1 secrendering time: 1 sectotal: 1.1 sec

only a little bit faster...(1.1 vs 1.8 sec)basically no server load => huge capacity increase!

Logged-in User / Subscriberbefore:initial page response time: 3 secrendering time (e.g. loading js/css/images): 1 sec total time: 4 sec

after:initial page response time: 0.1 secrendering time (include AJAX call:1 sec): 1 sectotal time: 1.1 sec

Capacity constant: AJAX call still needs to hit Rails300% faster!

[wait for applause]

development implications

less Rails, more JS1 user !== 1 (Rails) request

goodbye:current_usersessioncookies

testing

onCurrentUserReady(callback)callback when personalize API returns (or callback immediately for anonymous user)

before:- if logged_in? do stuff for logged-in user- else do stuff for anonymous user

after:Groupon.onCurrentUserReady(function(){ if (Groupon.currentUser.isAuthenticated) { do stuff for logged-in user } else { do stuff for anonymous user }});

analyticsProblem: Request loggingSolution: Tracking pixel (hit Nginx only, not Rails)

Problem: Content changesSolution: Dynamic tracking pixel

Problem: Tracking params (e.g. utm params, affiliate id, etc...)Solution: Store in cookie; append params to API request

a/b testing with FinchProblem: Finch uses view/controller logic to choose and track experiments and variants

- experiment 'Two vs. Three Step Subscription' do |e|

- e.variant 'Original' do %h1 Fill out this form to subscribe now

- e.variant 'Two Step' do %h4 Follow these two steps to subscribe

- e.variant 'Three Step' do %p Subscribe now - it only takes a few seconds

Finch.jsFinch.Experiments.DelayedJSExperiment = { defer: function() { var experiment = this; FinchDemo.onCurrentUserReady(function() { experiment.deferedRun(this); }); }, before: function() { $('#delayed').hide(); }, after: function() { $('#delayed').show(); }, variants: { original: function() { $('#delayed .original').show(); }, alternate: function() { $('#delayed .alternate').show();}, } }; $(function() { Finch.run(window); });

Finch.jsbased on Google's "Overlapping Experiment Infrastructure"written in coffee-scriptopen source soon-ishly~ 15k of JSdoesn't handle tracking/analytics/analysis side of testing (yet?)

the futurepure-JSON API requestsclient-side rendering (/w mustache.js)HTML5 storagedecouple from Rails

development practices:front/back-end integrationbetter testingbetter monitoring

@jonpliskejpliske@groupon.comgroupon.com/techjobs

Thank you!