Backpressure? Resistance is not futile. (Uphill Conf 2019)

Backpressure?
Resistance is not futile.
Jay Phelps | @_jayphelps

Jay Phelps
@_jayphelps
Senior Software Engineer
Citadel

Backpressure

A term borrowed from ﬂuid dynamics,
like in automotive exhaust and house
plumbing.

“Resistance or force opposing the
desired ﬂow of ﬂuid through pipes.”

desired ﬂow of ﬂuid through pipes.”
^ data through software.

desired ﬂow of data through software.”

i.e. “input is coming in faster
than we can output”

…but…what is Backpressure?

Let’s start with an analogy!

I Love Lucy: Chocolate Factory

"I Love Lucy" Job Switching - 1952 - CBS
"I Love Lucy" Job Switching - 1952 - CBS
video: https://bit.ly/1eUkJgG

Lucy has Backpressure!

She tries to set them to the side
(buffering)

Then she tries eating and hiding them
(dropping)

She needs to slow down the conveyor belt
(producer control)

Let’s talk software

Reading and writing ﬁles
File Systems

Writing is slower than reading

Read: 150 MB/s
Write: 100 MB/s
Example hard drive

Example hard drive
150 MB/s - 100 MB/s = 50 MB/sdeﬁcit

Imagine needing to read/write a 6 GB ﬁle
Example hard drive

Example hard drive
6 GB / 150 MB read = 40 seconds

Example hard drive
50 MB deﬁcit x 40 sec = 2 GB memory!

That’s a lot of wasted memory

Solution: only read as fast as you can write
(control the producer)

Most I/O libraries do this for you, automatically
Node.js Streams is a great example

const zlib = require('zlib');
const fs = require('fs');
const gzip = zlib.createGzip();
const input = fs.createReadStream('input.txt');
const output = fs.createWriteStream('input.txt.gz');
// handles backpressure for you
input.pipe(gzip).pipe(output);

Server-to-Server Communication

A
Server
B
Server
C
Server

A
Server
B
Server
C
Server
100 rps 75 rps

A B C
Server Server Server
60 sec * 25 rps = 1,500 rpm!
100 rps 75 rps

A B C
Server Server Server
100 rps 75 rps
60 sec * 60 min * 25 rps = 90,000 rph!

Solution: control the producer (or scale up)

…unfortunately, that isn’t easy

RSocket, gRPC, etc

UI Rendering

Throttling/debouncing keyboard input

High volume WebSockets

Events are coming in faster
than we can render them

Solution: control the producer?

Is this even a good User Experience?

Performance problems are often UX problems!

Buffer or Drop/Sample?

Maybe table virtualization too?

VirtualizedNOT Virtualized vs.

Backpressure Strategies

If you can, scale up your resources

Three fundamental strategies

Control the producer
Buffer
Drop

Control the producer
slow down/speed up is decided by consumer

const source = connectToSource();
source.pull(response1 => {
console.log(response1);
// later…
source.pull(response2 => {
console.log(response2);
});
});

Controlling is usually the ideal option
but not always viable

Buffer
accumulate incoming data spikes temporarily

Be careful with unbounded buffers!

Drop
sample a percentage of the incoming data

Throttle, debounce, etc

Not always acceptable to lose data

Libraries for handling Backpressure

Probably streams, but maybe not!

Push-based streams
RxJS, Bacon.js, xstream

Push: producer is in control

Pull-based streams
Node.js Streams, Web Streams, Async Iterators, IxJS

Pull: consumer is in control

It’s not unusual to use both push
and pull streams in the same app

“Resistance opposing the
desired ﬂow of data through software.”

Thanks!
@_jayphelps

Backpressure? Resistance is not futile. (Uphill Conf 2019)

Recommended

Recommended

More Related Content

More from Jay Phelps

More from Jay Phelps (6)

Recently uploaded

Recently uploaded (20)

Backpressure? Resistance is not futile. (Uphill Conf 2019)