tl;dr:Elasticache ti obbliga a utilizzare una singola istanza di redis, che non è ottimale.
La versione lunga:
Mi rendo conto che questo è un vecchio post (2 anni al momento in cui scrivo), ma penso che sia importante notare un punto che non vedo qui.
Su elastiche la tua distribuzione redis è gestita da Amazon. Ciò significa che sei bloccato con il modo in cui scelgono di eseguire il tuo redis.
Redis utilizza un singolo thread di esecuzione per letture/scritture. Ciò garantisce coerenza senza blocco. È un vantaggio importante in termini di prestazioni non gestire serrature e chiavistelli. La sfortunata conseguenza, tuttavia, è che se il tuo EC2 ha più di 1 vCPU non verrà utilizzato. Questo è il caso di tutte le istanze elastiche con più di una vCPU.
La dimensione predefinita dell'istanza elasticache è cache.r3.large , che ha due core.
In effetti, esistono diverse dimensioni di istanza con più vCPU. Molte opportunità per manifestare questo problema.
Sembra che Amazon sia già a conoscenza di questo problema, ma sembra un po' sprezzante al riguardo.
La parte che lo rende particolarmente rilevante per questa domanda è che sul tuo EC2 (poiché gestisci la tua distribuzione) puoi implementare multi-tenancy . Ciò significa che hai molte istanze del processo redis in ascolto su porte diverse. Scegliendo quale porta leggere/scrivere su/da nell'applicazione in base a un hash della chiave del record puoi sfruttare tutte le tue vCPU.
Come nota a margine; un'implementazione di redis elasticache su una macchina multi-core dovrebbe sempre avere prestazioni inferiori rispetto all'implementazione di memcached elasticache sulla dimensione dell'istanza. Con la multi-tenancy, redis tende ad essere il vincitore.
Aggiornamento:
Amazon ora fornisce parametri separati per la CPU dell'istanza redis, EngineCPUUtilization. Non hai più bisogno di calcolare la tua CPU con la moltiplicazione scadente, ma la multi-tenancy non è ancora implementata.
