Hacker News Reader

Comment by misterbowfinger | Hacker News Reader

I don't quite understand what "pipelining" means. Can anyone TL;DR?

Please don't bring lazyweb to HN. We can already see the duplicate replies (which are on the edge of karma whoring, for lack of a better term) filling the comment thread.

There is redis documentation for this, which is literally the first result for searching "pipelining redis":

https://redis.io/topics/pipelining

HN has a standard which at minimum is above LMGTFY.

Woah chill out. I don't think it's that big of a deal to ask a question, especially for newbies who find documentation intimidating and tough to get through.

To be fair, if getting through the documentation for a feature is tough, then engaging in the discussion about its performance and the potential impacts of these recent mitigations will be much, much more difficult.

That's fair. Although I usually look to HN to hopefully find someone who provides clarity over situations like this. Performance impacts are really easy to interpret incorrectly.

I can see from your profile that your account is "half troll", and there is not really room for troll accounts on HN, while we do value legitimate "devil's advocate" or contrary positions. This is how we maintain our level of discourse.

In the old days of the internet, asking for anything searchable is the action of last resort, and generally considered quite rude unless truly unfindable or incomprehensible. Taking action on one's own intellectual curiosity is invaluable for education.

Not to play devil's advocate here but there's no harm in labeling oneself as a troll unless his actions meet the criteria. I certainly don't believe he's trolling in this instance nor do his previous comments suggest past behavior of such. Anyways, just wanted to point out that this is a straw man argument.

Fairly certain this is talking about Redis pipelining (https://redis.io/topics/pipelining). It let's you send multiple commands to Redis without waiting for a response between each one.

Pipelined operations don't wait for the preceding operation to complete before they start. So this will be multiple gets being issued simultaneously.

This is often used to reduce latency but only works with operations that don't depend on the preceding operation.

It's great if you want to run something like "Here's a bunch of SET operations. Do them and get back to me when they're all finished."

It's basically just consolidating multiple requests into one larger request.

So applications that use Redis mainly for caching won't be hit as hard then?

Applications that don’t use Redis as a persistent store, and enable pipelining, will be hit less hard, yes. Applications that connect to Redis remotely will also be hit less hard — loopback makes this somewhat of a worst-case scenario.

Ahhhh that's this line was about:

> Test performed with AOF enabled

AOF is a type of persistence: https://redis.io/topics/persistence

Most of the time, I've used Redis with (I think) RDB persistence, just in case. Usually we've used it as an in-memory cache.

Ok, that makes a lot of sense, thanks!

Pipelining is buffering multiple commands into one network packet, otherwise each command is a separate packet.

Not necessarily. The relationship to packets is pretty thin. Pipeline mode just avoids the wait after each command before beginning the next, the same thing SMTP can do.

Well, not necessarily a single packet depending on the amount of data, but one send+receive operation versus one for every command.

https://redis.io/topics/pipelining

Reply on news.ycombinator.com