Skip to content
0:00 / 0:00

#latency#taillatency#jeffdean

Jeff Dean: "Achieving Rapid Response Times in Large Online Services" Keynote - Velocity 2014

O'Reilly

202K subscribers • 24 videos on Hallway

YouTube
  • Recommended by 2 people: 1 in engineering communities and 1 curated list.
  • Presented by Jeff Dean, Google Senior Fellow

Intermediate. Assumes working knowledge.

46K views12 years ago2 recommendations

Distributed systemsSystems programmingScaling and large-scale architectureConcurrency and parallelismNetworking and protocols

Jeff Dean explains techniques for managing tail latency and achieving rapid response times in large-scale distributed systems.

Jeff Dean's keynote from the 2014 O'Reilly Velocity conference in Santa Clara, CA. Today's large-scale web services provide rapid responses to interactive requests by applying large amounts of computational resources to massive datasets. They typically operate in warehouse-sized datacenters and run on clusters of machines that are shared across many kinds of interactive and batch jobs. As these systems distribute work to ever larger numbers of machines and sub-systems in order to provide interactive response times, it becomes increasingly difficult to tightly control latency variability across these machines, and often the 95%ile and 99%ile response times suffer in an effort to improve average response times. As systems scale up, simply stamping out all sources of variability does not work. Just as fault-tolerant techniques needed to be developed when guaranteeing fault-free operation by design became unfeasible, techniques that deliver predictably low service-level latency in the presence of highly-variable individual components are increasingly important at larger scales. In this talk, I'll describe a collection of techniques and practices lowering response times in large distributed systems whose components run on shared clusters of machines, where pieces of these systems are subject to interference by other tasks, and where unpredictable latency hiccups are the norm, not the exception. Some of the techniques adapt to trends observed over periods of a few minutes, making them effective at dealing with longer-lived interference or resource contention. Others react to latency anomalies within a few milliseconds, making them suitable for mitigating variability within the context of a single interactive request. I'll discuss examples of how these techniques are used in various pieces of Google's systems infrastructure and in various higher-level online services. In this talk, I'll describe a collection of techniques and practices lowering response times in large distributed systems whose components run on shared clusters of machines, where pieces of these systems are subject to interference by other tasks, and where unpredictable latency hiccups are the norm, not the exception. Some of the techniques adapt to trends observed over periods of a few minutes, making them effective at dealing with longer-lived interference or resource contention. Others react to latency anomalies within a few milliseconds, making them suitable for mitigating variability within the context of a single interactive request. I'll discuss examples of how these techniques are used in various pieces of Google's systems infrastructure and in various higher-level online services. This talk presents joint work with Luiz Barroso and a number of other colleagues at Google. About Jeff Dean (Google): Jeff joined Google in 1999 and is currently a Google Senior Fellow in Google's Knowledge Group. He has co-designed/implemented five generations of Google's crawling, indexing, and

Why it's here

2 people recommend this

What people say. Highly recommended for understanding how to handle latency variability and request replication at scale.

awesome-scalabilitycurated list on GitHubRecommends

Under “Talk”

Achieving Rapid Response Times in Large Online Services - Jeff Dean, Google Senior Fellow

u/hastorin r/haskell • Recommends

On “Behaviour of Servant (or wai?) under concurrent load?”

…ave two issues - either it doesn't compose, or if the request is coming from an end-user, we can't apply backpressure. You can also see that LIFO is never used in large scale systems like those at Google. See this talk by Jeff Dean on this exact topic: Jeff Dean: "Achieving Rapid Response Times in Large Online Services" Keynote - Velocity 2014 link to this video If you have very low fanout and replicate requests to multiple backends, maybe it could fly, but 95th percentile latency is typically *not* what you want to optimize for, it's the 99% or 99.99% percentile that is what people complain about.…