[QUESTION] Redis StandAlone slower than Redis-Cluster on K8s

[stefanofalangone]

At my company, we have an installation of Redis standalone (no replicas) which we are considering as a shared point for a microservices architecture running on a Kubernetes Cluster.
We wish to achieve scalability, and to do so, we thought it was appropriate to use Redis-Cluster instead, considering that we are dealing with hundreds of pods in r/w.

After the installation of redis-cluster, we run multiple tests, but we had worse performances in comparison of the standalone one.

We thought it was a problem of the machine, so we dedicated a nodepool with 3 nodes just for redis (24 CPUs, 192Gb of RAM).
Well, our performances were slightly increased but the SET operations are still slower than the standalone installation.
We tried with 6 redis-nodes, and using redis benchmark we collected this results.

**redis-standalone**
160kb writes (redis-benchmark -q -n 100000 -d 160000)
SET: 9852.22 requests per second, p50=2.559 msec
GET: 10663.25 requests per second, p50=1.239 msec

**redis-cluster, 3 master, 3 slave**
160kb writes (redis-benchmark -n 100000 -t set,get -d 160000 -q -h redis-cluster.redis-cluster.svc.cluster.local -p 6379 --cluster -a nlU9Pgbtd2)
SET: 2217.29 requests per second, p50=5.631 msec
GET: 10766.58 requests per second, p50=2.047 msec

**redis-cluster, 6 master, 0 slave**
160kb writes (redis-benchmark -n 100000 -t set,get -d 160000 -q -h redis-cluster.redis-cluster.svc.cluster.local -p 6379 --cluster -a DClhsBfE7f)
SET: 3491.50 requests per second, p50=6.231 msec
GET: 15368.07 requests per second, p50=1.343 msec

For reference, we installed it throught bitnami chart, putting the resourcesPreset to 2xlarge
"2xlarge" ("requests" (dict "cpu" "1.5" "memory" "4096Mi" "ephemeral-storage" "50Mi")
"limits" (dict "cpu" "6.0" "memory" "12288Mi" "ephemeral-storage" "1024Mi")

I would like to understand why the SET in redis-cluster is much slower than the GET requests, why we have worse performances than the standalone and how we could improve those.

Thank you in advance for reading 'til here!