Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Caching, why not?

Caching, why not?

Highload meetup: talks by Megogo, 2015

dkovalenko

July 11, 2015
Tweet

Other Decks in Technology

Transcript

  1. About me • Dmitriy Kovalenko @dkovalenko_fun • TeamLead @ x2sy:

    Megogo • Actively using: Scala, php • Also: Clojure, golang
  2. About us • > 4 million users every day •

    > 30000 hours of video content • Web, iOS, Android, SmartTV, OTT Boxes • CIS, Baltics, Europe
  3. Agenda • Caching across tiers: 1. Browser 2. Frontend server/proxy

    3. Application • Cache infrastructure • Microservices and caching
  4. Use CDN, Carl! • Move your Images, JS, CSS ->

    CDN • Assets minifying, response gzipping
  5. Reverse proxy • Varnish Cache • Nginx • Use your

    cache store directly (CouchDB, Memcached) • Split your page, think about SSI/ESI includes
  6. frontend server caching pros: • High speed • Zero overhead

    for application • Usually can be applied without application change
  7. frontend server caching cons: • Hard to debug • Hard

    to get right • Changes in application needs additional synchronization
  8. Application cache pros: • Much controllable than frontend cache •

    Can use Application context • Swapping implementations in not a problem
  9. Problems to think about • Key selection, Cache Tags •

    Invalidation schema • Cold start/full flush • Dogpile effect • Embedded or External • Local or Distibuted
  10. <?php $data = $cache->get('some_key'); if ($data === false) { $data

    = getFromDB(); $cache->set($data); } return $data;
  11. There are only two hard things in Computer Science: cache

    invalidation and naming things. ! -- Phil Karlton
  12. Great caching is like great sex. It hides all the

    real problems. ! @vivekhaldar Questions?