tl;dr:Elasticache dwingt je om een enkele instantie van redis te gebruiken, wat niet optimaal is.
De lange versie:
Ik realiseer me dat dit een oud bericht is (2 jaar op het moment van schrijven), maar ik denk dat het belangrijk is om een punt op te merken dat ik hier niet zie.
Op elasticache wordt uw redis-implementatie beheerd door Amazon. Dit betekent dat je vastzit aan de manier waarop ze je redis willen uitvoeren.
Redis gebruikt een enkele uitvoeringsthread voor lezen/schrijven. Dit zorgt voor consistentie zonder vergrendeling. Het is een belangrijke troef in termen van prestaties om geen sloten en grendels te beheren. Het ongelukkige gevolg is echter dat als uw EC2 meer dan 1 vCPU heeft, deze ongebruikt blijft. Dit is het geval voor alle Elasticache-instanties met meer dan één vCPU.
De standaard grootte van de elasticache-instantie is cache.r3.large , die twee kernen heeft.
In feite zijn er een aantal instantiegroottes met meerdere vCPU's. Veel kansen voor dit probleem om zich te manifesteren.
Het lijkt erop dat Amazon al op de hoogte is van dit probleem, maar ze lijken er een beetje afwijzend tegenover te staan.
Het deel dat dit bijzonder relevant maakt voor deze vraag, is dat u op uw EC2 (aangezien u uw eigen implementatie beheert) multi-tenancy kunt implementeren . Dit betekent dat je veel exemplaren van het redis-proces hebt die op verschillende poorten luisteren. Door in de toepassing te kiezen naar welke poort u wilt lezen/schrijven van/naar de toepassing op basis van een hash van de recordsleutel, kunt u al uw vCPU's benutten.
Als een kanttekening; een redis elasticache-implementatie op een multi-core machine zou altijd onder moeten presteren in vergelijking met memcached elasticache-implementatie op de instantiegrootte. Met multi-tenancy is redis meestal de winnaar.
Bijwerken:
Amazon biedt nu afzonderlijke statistieken voor uw redis-instantie-CPU, EngineCPUtilization. U hoeft uw CPU niet langer te berekenen met de slordige vermenigvuldiging, maar multi-tenancy is nog steeds niet geïmplementeerd.