KeyDB and TLS performance penalty

[zamazan4ik]

According to the Redis documentation (and the corresponding discussion redis/redis#7595), Redis has a significant (IMHO) performance penalty from enabling TLS.

We are interested in enabling TLS for our Redis instances (for security reasons) but since Redis has such bad performance in this case we consider switching to KeyDB in places where TLS matters.

I have tried to find KeyDB TLS benchmarks but with no success so I asking here - does KeyDB suffer from enabling TLS in the same way as Redis? Maybe someone already performed the corresponding benchmarks and could share some insights regarding it. The same question applies to ACL configuration functionality - does it have any measurable performance penalty in practice?

Thanks in advance!

[JohnSully]

At Snap we use TLS for all our caches. The performance penalty is much lower for KeyDB as we multithread TLS connections and do the encryption outside the global lock.

It’s been a long time since I benchmarked it vs no TLS but I think it’s around a 10% penalty if my memory serves. You can use memtier to verify.

https://github.com/RedisLabs/memtier_benchmark

[zamazan4ik]

Thanks for the answer!

From your experience, is there any measurable performance impact from enabling ACL in KeyDB?

[JohnSully]

The code looks reasonably efficient so I don’t think it will hurt you. ACLs are checked in the global lock though. I don’t have any experience benchmarking them.