tl;dr:O Elasticche força você a usar uma única instância de redis, que é abaixo do ideal.

A versão longa:

Sei que este é um post antigo (2 anos no momento da redação deste artigo), mas acho importante observar um ponto que não vejo aqui.

No elasticache, sua implantação do redis é gerenciada pela Amazon. Isso significa que você está preso à maneira como eles escolhem executar seu redis.

O Redis usa um único thread de execução para leituras/gravações. Isso garante consistência sem travamento. É um grande trunfo em termos de desempenho não gerenciar fechaduras e travas. A consequência infeliz, porém, é que, se o seu EC2 tiver mais de 1 vCPU, eles não serão usados. Esse é o caso de todas as instâncias do elasticache com mais de uma vCPU.

O tamanho padrão da instância do elasticache é cache.r3.large , que tem dois núcleos.



Na verdade, há vários tamanhos de instância com várias vCPUs. Muitas oportunidades para este problema se manifestar.



Parece que a Amazon já está ciente desse problema, mas eles parecem um pouco desdenhosos.



A parte que torna isso especialmente relevante para esta pergunta é que em seu EC2 (já que você está gerenciando sua própria implantação), você pode implementar multilocação . Isso significa que você tem muitas instâncias do processo redis escutando em portas diferentes. Ao escolher em qual porta ler/gravar no aplicativo com base em um hash da chave do registro, você pode aproveitar todas as suas vCPUs.

Como uma nota rodapé; uma implantação do elasticache do redis em uma máquina com vários núcleos deve sempre ter um desempenho inferior em comparação com a implantação do elasticache do memcached no tamanho da instância. Com multilocação, o redis tende a ser o vencedor.

Atualizar:

A Amazon agora fornece métricas separadas para a CPU da sua instância redis, EngineCPUUtilization. Você não precisa mais calcular sua CPU com a multiplicação de má qualidade, mas a multilocação ainda não está implementada.