Skip to content
GitLab
Next
Closed
Issue created by Robert May@robotmay_gitlab🔴Developer

Caching Workshop

What

Organise a workshop for GitLab team members to discuss caching techniques and implementations in the context of the GitLab Rails application.

Who

Presenter

Me 😺 (known cheapskate who has used caching to avoid big server bills pretty much my entire career)

Attendees

  • Anyone who can attend live - I'm not opposed to running it in multiple timezones
  • Recordings for viewing later on and for people outside of GitLab

When

Friday 4th of June

Session events

  1. Session 1 recording, 2-3pm GMT
  2. Session 2, 4-5:30pm GMT

Session 1

Slide Deck

Caching_Workshop.pdf

Recordings

Session 2

Q&A/Suggestions Issue

gitlab#332666 (closed)

Recordings

Content

Background information and setup

  • Why use caching?
  • A little of my background in caching
  • Setting your environment up for caching
    • Enable caching in development with rake dev:cache
    • Testing caches and our test helpers for caching
  • Why we, and pretty much everyone, use Redis-pretending-to-be-memcached rather than memcached itself, and a few pros/cons of this

Caching methodology

  • Cache levels
    • Probably not official names but how I think of them:
      • High-level caching
        • HTTP caching
        • HTTP caching in a reverse proxy cache
        • HTML page caching
        • View caching
        • Fragment caching
      • Low-level caching
        • Method caching
        • Request caching
        • Read-through/write-through SQL caching
        • Novelty caches for specific use-cases
  • Rails' built-in caching helpers
  • How memcached/Redis expire keys
  • How Rails expires keys
  • Explicit deletes vs cache key rotation vs TTL (Time to Live)
  • Existing GitLab-specific low-level caches
    • Repository method caches and the stores behind them
  • Request caching

Caching "gotchas"

  • Common problems
  • What to look for when adding new caching
  • How it can go slightly wrong (stale data)
  • How it can go very wrong (showing user-specific data to someone else)

View-level caching (main focus)

  • Benefits of view-level caching
    • Use examples from previous applications I've built if possible
    • Existing examples from GitLab
    • Performance issues with Rails templates
  • Difficulties associated with view-level caching
    • Multiple caches and network latency
      • Touch on the workarounds for this
    • Cache keys
    • Cache expiry
    • User-specific data
    • GitLab-specific issues
      • Lack of cache_key rotation
      • Lots of user-specific data
      • Ownership of the view layer
  • Why ERB is oddly easier to cache than HAML
  • Hacks and unusual techniques
    • multi-fetching
    • chunky_cache
    • Adding awkward stuff to cache keys
    • Using JavaScript to get around limitations

Case studies

  • Look at a known endpoint where caching has improved it
    • Analyse why it was effective
    • Explain techniques used
  • Crowd-source an endpoint or view to investigate live on the workshop (live coding 🙀)
    • Might take a couple of attempts to find something with viable improvements
    • Attempt to put together a draft MR that improves the view rendering

Materials

Edited by Sean Carroll