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.

While the delivery leaves something to be desired, I second what he's saying. You're essentially telling people "please do the work for me since I'm too lazy to". It's the kind of low effort post that plagues reddit. I love reddit, but appreciate that there's an alternative for higher quality discussion. Part of keeping discussion high quality is signaling to others what's acceptable and not acceptable. Simply ignoring your question wouldn't communicate to others that questions like yours should be avoided.

I get that. I'm happy to be downvoted to oblivion :)

Although, in a lower comment, talking through how the performance benchmarks were about using Redis for persistence was really helpful to me. I don't think I would have ever had that realization had I not asked the "dumb question" at first.

My hesitation with just asking my real question on using Redis for caching was that I didn't really understand what "pipelining" is. I've misinterpreted documentation so many times that I've found it's useful to ask dumb questions, even if the only value is to get validation that you were right.

Lower comment: https://news.ycombinator.com/item?id=16081482

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