when dispatcher caching is not enough

The future of digital marketing. London, Poland, Copenhagen. © 22/06/2015

When dispatcher caching is not enough…

Jakub WądołowskiSenior Systems Engineer @ Cognifide

twitter.com/jwadolowski


Agenda

The What What was the problem about?

The Why Why we decided to go for Content Delivery Network (CDN)?

The How How it was implemented?


THE WHAT


It all started in 2012…

www.flickr.com/photos/nasahqphoto/16327416694


To be perfectly honest, initially it was rather like that…

www.flickr.com/photos/garryknight/5703519506


The client

EU pharmaceutical company75 offices across the globeOver 40 000 employeesMedical products available worldwide (180+ countries)

www.flickr.com/photos/worak/2258271659


Requirements

Country specific brochureware websites for medical productsiPad app for sales representativesSingle point for content entryMultiple integration points (SSO, user/device authentication, etc.)CQ 5.5, upgrade to AEM 6.1 in progress


Main components

Brochureware website

iPad app AEM Authoring


Logical Architecture

Single datacenter in LondonREST-like API for iPad appIntegrations with local and remote services


Initially it was just Spain, Argentina and Sweden


6 months later the number of countries was tripled


To finally reach 21 and it is still not over


THE WHY


“Our team in Argentina complains that the app feels slow. They can’t download presentations sometimes. Could you please

investigate that?”

Mr B.

www.flickr.com/photos/r4vi/8640618489


Problems

Latency, latency, latency…Way too high round trip times (RTT)TimeoutsBroken streamsConnection resetsPoor Internet connections in some areas


Solutions


When initial excitement was gone…

How we’re going to sync the content (both ways)?What about deployments?Do we have enough licenses to set up the new stack in a proper way?What’s the best way to implement content sharding?How long it will take to implement all of these things?


PoC conclusion

www.flickr.com/photos/geishaboy500/2496995573


The road to CDN

We can’t just cache more on dispatcherThis is a very well known problemLet’s use the right tool to solve the problem the right wayContent Delivery Network (CDN) is the way to go!


CDN definition

“(…) CDN is a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance. CDNs serve a large fraction of the Internet content today (..).”, Wikipedia


AEM + CDN


CDN, right?

www.flickr.com/photos/pictures-of-money/16678590844


That's not necessarily true nowadays…

www.flickr.com/photos/halfrain/14410890555


Why Fastly?

Pay-as-you-go modelPowered by VarnishHighly customizable (ability to upload your own VCL)150 ms to purge – globally~5 sec to change a config through the web APISSD powered servers connected to T1 networksReal-time insight what’s happening (graphs, logs, etc)Great support


Still not convinced?


THE HOW


Uhh… ok, how should I start?

www.flickr.com/photos/kleuske/8004416109


The logs!

www.flickr.com/photos/martinbamford/5638834940


Logs and content structure

grep, awk, sed - all of these are your friendsCount your requestsLeverage the power of log monitoring tools (ELK, Splunk, etc.)Plan your content structure carefully


Look for patterns

www.flickr.com/photos/wwarby/4915777722


Request patterns

If it is a GET request and starts with /bin/myapp/v[1-2]/a_string.json then it is X

All requests to /content/something/*/_jcr_content.zip end with 302 to /some/path/to/file.zip


Assign these patterns to multiple buckets

www.flickr.com/photos/ddebold/15991919514


Content groups/buckets

Public contentPrivate contentContent available for authorized users only


Varnish in 1 slide!

Reverse HTTP proxyIn-memory time based cacheBlazing-fastBig “state” machineVarnish Configuration Language (VCL)Full control of HTTP flow


General caching rules

Cacheable methods: GET, HEADCacheable response codes: 200, 203, 300, 301, 302, 410, 404“Cache-Control: private” if not defined otherwise


Let’s start with the iPad app

www.flickr.com/photos/pestoverde/15048774061


iPad content

2 content groups8 request patternsTTL varies from 10 minutes to 7 days35/65 dynamic/static content (frequently changing JSON files vs PDFs/PNGs)

All REST API responses are private


Private content

Private content is cacheableWhat makes HTTP response private? It is tied up with user session – in other words HTTP request carried

unique authorization cookie


Is it really safe to cache that type of content?

www.flickr.com/photos/hyku/368912557


Private cache

Varnish cache is a key-value storeDefault key: req.url + req.http.hostreq.url + req.http.host + sessionId = private cache space - voila!


Dynamic means uncacheable?

www.flickr.com/photos/gsfc/7402445224


Dynamic content

Cache usually brings some trade-off Updates won’t be instantaneous TTL has to expire, or a purge request has to be triggered

CDN is the way to go if you accept this delay


Content purging

www.flickr.com/photos/librariesrock/13522859053


Content purging

Fastly exposes purge REST APIPurge URL Purge Key Purge AllPurge vs Soft Purge


Results

www.flickr.com/photos/89228431@N06/11322953266


iPad app statistics

Hit ratio: 48,4%

Cache coverage: 65,3%

Requests: 83K


What about the speed?

www.flickr.com/photos/129341635@N02/16609174727


Speed boost

Presentation download Europe: up to 21% faster South America: up to 50% faster APAC: up to 83% faster

API responses Europe: up to 60% faster South America: up to 40% faster APAC: up to 55% faster


Issues?

www.flickr.com/photos/giuseppemilo/15414290956


Crimes against cacheability

www.flickr.com/photos/alancleaver/4121423119



Adding Set-Cookie to every response Auth cookie is not revoked in the browser after logout TBD


“iPad app performance is much better now! But we still have some issues with authoring. It is really slow in some countries.”

Mr B.

www.flickr.com/photos/r4vi/8640618489


CDN in front of authoring?

I was rather skepticalWay too dynamic to be considered cacheable?What kind of improvement we might get? 5-10%? Is it worth it?Don’t know how, but it has been decided to roll things out


CDN + AEM Author

3 content groups36 request patternsTTL up to 14 daysMostly dynamic + static web GUI resourcesA lot of assets common for every logged in user


Authorized only!

www.flickr.com/photos/rudyjuanito/5170435542


Authorize at the edge

CDN knows nothing about user sessionThe goal is to cache common content for successfully authorized usersAuthorize them at the edge!


Auth tokens

www.flickr.com/photos/cfortier/426610972


Auth tokens

2nd auth cookie (token), readable by CDNHMAC function2 auth cookies are tied togetherReference implementation: https://github.com/fastly/token-functionsPrivate key shared between AEM and CDNCDN can evaluate user session without request to AEM

https://github.com/fastly/token-functions

https://github.com/fastly/token-functions


www.flickr.com/photos/spacexphotos/16169087563

96,4%


Author statistics

Hit ratio: 96,4%

Cache coverage: 45,1%

Requests: 97K



Adding Set-Cookie to every response Auth cookie is not revoked in the browser after logout “Vary: Cookie” usage


Summary

www.flickr.com/photos/andrewhurley/6254409229


Summary

Traffic growth is no longer an issue Over 2 TB monthly reaches CDN servers ~5,5 million HTTP requests per month just ~570 GB was passed through to AEM

License, budget and time savingsMore than satisfying resultsVery small changes in the AEM app itselfHappy client


[email protected]/jwadolowski

twitter.com/jwadolowski

linkedin.com/in/kubawadolowski/en

www.flickr.com/photos/jeffdjevdet/18027482924

when dispatcher caching is not enough

Technology

future of digital marketing

london rest

latency way

medical products ipad

ipad app integrations

content sharding

problems latency

best way