Gebaseerd op release-opmerkingen, denk ik van wel. Hier is een stukje kleine informatie:
Ondanks de welverdiende reputatie van Redis voor hoge prestaties, is de single-threaded architectuur controversieel onder ingenieurs die zich afvroegen of Redis nog sneller zou kunnen zijn. Redis 6 luidt een nieuw tijdperk in:hoewel het een kerninterface voor gegevenstoegang met één thread behoudt, is I/O nu threaded.
Door de tijd die besteed wordt aan het lezen en schrijven naar I/O-sockets te delegeren aan andere threads, kan het Redis-proces meer cycli besteden aan het manipuleren, opslaan en ophalen van gegevens, waardoor de algehele prestaties worden verbeterd. Deze verbetering behoudt de transactiekenmerken van eerdere versies, zodat u uw applicaties niet opnieuw hoeft te bedenken om te profiteren van de verbeterde prestaties. Evenzo kan de single-threaded DEL-opdracht van Redis nu worden geconfigureerd om zich te gedragen als de multi-thread UNLINK-opdracht die beschikbaar is sinds Redis versie 4.
De prestaties van een lokale variabele zijn bijna altijd onverslaanbaar. Ten slotte zal zelfs een database met zo hoge prestaties als Redis veel langzamer zijn dan toegang tot iets van de stapel of heap. Redis 6 voegt een nieuwe techniek toe voor geavanceerde clientbibliotheken om een cachelaag aan de clientzijde te implementeren om een subset van gegevens in uw eigen proces op te slaan. Deze implementatie is slim genoeg om meerdere updates van dezelfde gegevens te beheren en uw gegevens zo synchroon mogelijk te houden, terwijl de voordelen van Redis behouden blijven met de snelheid van lokale variabelen.
U kunt het ook controleren/vergelijken met redis-benchmark of memtier-harnas voor uw instantie/workloadprofiel.