tl;dr:Elasticache lo obliga a usar una sola instancia de redis, lo cual es subóptimo.
La versión larga:
Me doy cuenta de que esta es una publicación antigua (2 años en el momento de escribir esto), pero creo que es importante tener en cuenta un punto que no veo aquí.
En elasticache, su implementación de redis es administrada por Amazon. Esto significa que está atascado con la forma en que elijan ejecutar su redis.
Redis usa un solo hilo de ejecución para lecturas/escrituras. Esto asegura la consistencia sin bloqueo. Es un activo importante en términos de rendimiento no administrar bloqueos y pestillos. Sin embargo, la desafortunada consecuencia es que si su EC2 tiene más de 1 vCPU, no se usarán. Este es el caso de todas las instancias de Elasticache con más de una vCPU.
El tamaño predeterminado de la instancia de Elasticache es cache.r3.large , que tiene dos núcleos.
De hecho, hay una serie de tamaños de instancia con varias vCPU. Muchas oportunidades para que este problema se manifieste.
Parece que Amazon ya está al tanto de este problema, pero parecen un poco desdeñosos.
La parte que hace que esto sea especialmente relevante para esta pregunta es que en su EC2 (dado que está administrando su propia implementación) puede implementar multiusuario . Esto significa que tiene muchas instancias del proceso redis escuchando en diferentes puertos. Al elegir en qué puerto leer/escribir en/desde la aplicación en función de un hash de la clave del registro, puede aprovechar todas sus vCPU.
Como nota al margen; una implementación de redis elasticache en una máquina de varios núcleos siempre debe tener un rendimiento inferior en comparación con la implementación de memcached elasticache en el tamaño de la instancia. Con multiusuario, redis tiende a ser el ganador.
Actualización:
Amazon ahora proporciona métricas separadas para la CPU de su instancia de redis, EngineCPUUtilization. Ya no necesita calcular su CPU con la multiplicación de mala calidad, pero aún no se implementa la tenencia múltiple.
