Mediavine is currently *heavily* leaning a CDN which allows them to scale a sizable amount of traffic with low cost Heroku dynos. Tim will talk about how they leverage Fastly's CDN with a number of use cases and also explore Fastly's feature set.
What is a CDN? Why would you use one? • Mediavine’s Use Case • Fastly Setup • Cover specific CDN features • Fastly w/ Rails • How we deploy: watch a video!
company called Mediavine (fully distributed company, 13 in the Department, around 60 employees total) • I do not code a whole lot anymore, hence this non-code presentation • Career Path: Help Desk => Configuration Management => Java => .NET => Rails => Backbone.js => Ember.js => Engineering Leadership => React.js => Engineering Leadership
for large-capacity, low-cost file storage in one specific geographical region. (The storage and bandwidth costs are quite low) • A Content Delivery Network proxies and caches web data at edge locations as close to users as possible.
JavaScript tooling (previously to be JS returned in a Rails view…) 2. Put a script on the pages of a publisher’s site which will then insert ads (through Header Bidding) 3. $$$$$$
dozen times a day from developer code changes • Script changes any number of times from Admin or Publisher configuration changes • Changing a color on their GDPR buttons • Turning off adhesion video • Etc • Video Player • AMP Script
'Surrogate-Key': `web ${slug}` These are headers set by your “origin” server response. “Cache-Control” Says that you want Fastly to cache your resources forever but send headers to browsers so that they don't cache it at all (so that every browser miss hits Fastly but isn't a cache miss from your service).
caching as it allows for the asset revalidation process to happen in the background. When this directive is present in the HTTP response header, it tells caches that they can continue serving the current (stale) assets while an asynchronous validation is attempted. max-age=2592000, stale-while-revalidate=60 The above tells the cache to deliver the same asset for 30 days and once that period is up, it has 60 seconds to validate the asset asynchronously via the origin server. This means that not only will users receive the latest versions of an asset, but they will also experience faster load time.
prevent errors and ultimately, broken pages. Instructs the cache to update the content every 30 days, but if the origin is down then show stale content for a day (86400 seconds).
selectively purge related content. Using the Surrogate-Key header, you can tag a group of objects with a key and then use it to purge multiple pieces of content at once.
a specific Point of Presence (POP) as a shield node to your origins. Once enabled, all requests to your origin will go through the datacenter you designate, increasing the chances of getting a HIT for a given resource. If a different POP doesn't have a specific object, it will query the shield (provided it's not down for maintenance) instead of your origins. Without shielding enabled, when the first request for content arrives at POP A, the POP does not have the content cached. It passes the request along to a customer's origin server to get the content. Once the content is retrieved, POP A caches it and sends it on to the user. When a second request for that same content arrives at POP A, the content is already cached. No request goes to the customer's origin server. It's merely sent from the cached copy.
content arrives at the POP A, that POP does not have the content cached. It passes the request along to the shield POP, which also doesn't have the content cached. The shield POP passes the request along to the customer's origin server. It then caches the content that's retrieved and passes it along to POP A. POP A then passes the content along to the user. When a second request for that same content arrives at POP A, the content is already cached, so no request goes to the shield POP or the customer's origin server. If the second request were to arrive at POP B instead of POP A, however, the request would be passed along to the shield POP. That shield POP already has a cached copy from the first request to POP A. No future requests for the content would be passed along to the customer's origin server until the shield POP's cached copy of it expires. *** Had an issue when our origin server was down ***
EU and set gdpr accordingly*/ if (req.url ~ "^/tags") { if (client.geo.country_code ~ "BE|BG|CZ|DK|DE|EE|IE|EL|ES|FR|HR|IT|CY|LV|LT|LU|HU| MT|NL|AT|PL|PT|RO|SI|SK|FI|SE|UK|GB|GR") { set req.url = querystring.set(req.url, "gdpr", "1"); } } “The scripting language used to configure and add logic to Varnish caches” The scripting language used to configure and add logic to Varnish caches. Can use for things like A/B testing
by Surrogate Key(s) • Soft Purge (stale_while_revalidate) Our Instant Purge feature allows you to cache and invalidate content almost as soon as it’s updated on your origin — within 150 milliseconds or less across our global network.
tag any response you wish to cache with unique Surrogate-Key HTTP Header(s) and then hit the Fastly API purge endpoint with the surrogate key when the response changes. The purge instantly replaces the cached response with a fresh response from origin. • This plugin provides three main things: • Instance and class methods on ActiveRecord objects for surrogate keys and purging • Controller helpers to set Cache-Control and Surrogate-Control response headers • A controller helper to set Surrogate-Key headers on responses
timtyrrell
yokawasa
lycorptech_jp
mochizuki875
bengo4com
tsukuha
duelist2020jp
ishikawa_satoru
shotashiratori
lana2548
minorun365
yamaguchitk333
trallard
eileencodes
stephaniewalter
tammyeverts
jakevdp
reverentgeek
denniskardys
pedronauck
addyosmani
chrisshort
cassininazir
