Ajuste de desempenho Redis

Primeiro, você pode querer ler a Página de referência Redis. Ele fornece um bom resumo dos principais pontos a verificar para sintonizar Redis.

Mesmo supondo que não use pipelining, 300 entram em 150 ms não é assim tão eficiente. Significa que a latência média é de 500 Nós. No entanto, isso realmente depende do tamanho de seus objetos. Objectos maiores, mais latência. Na minha antiga caixa AMD de 2 GHz, posso medir 150 latências dos EUA para objetos pequenos (alguns bytes).

Para verificar rapidamente o latência média da instância Redis, você pode usar:

$ redis-cli --latency

Não se esqueça de usar uma versão recente do Redis (não 2.4) para obter esta opção. Nota: 2.4 é bastante antigo agora, use Redis 2.6-compile sua própria versão Redis se necessário, é realmente simples.

Para executar rapidamente uma referência para estudar latência, você pode lançar:

$ redis-benchmark -q -n 10000 -c 1 -d average_size_of_your_objects_in_bytes

Funciona com uma ligação única e sem tubulação, de modo que a latência pode ser deduzida do rendimento. Tente comparar o resultado destes benchmarks com o valores medidos com a sua aplicação.

Há uma série de pontos que você pode querer verificar:

Que Biblioteca de clientes Redis usa? Com que língua de desenvolvimento? Para algumas linguagens de script, você precisa instalar o módulo hiredis para obter um cliente eficiente. A tua máquina é VM? Em que so? As ligações à Redis são persistentes? (ou seja, não é suposto ligar-se/desligar a cada pedido HTTP da sua aplicação servidor).

Porque é que é melhor com o memcached? Bem, uma única instância memcached é certamente mais escalável, e pode ser mais sensível do que uma única instância Redis, uma vez que pode ser executado em vários threads. Redis é rápido, mas simples - a execução de todos os comandos é serializada. Assim, quando um comando está em andamento para uma conexão, todos os outros clientes têm que esperar - uma latência ruim em um determinado comando também irá afetar todos os comandos pendentes. Em geral, com um baixo rendimento, no entanto, o desempenho é comparável.

A 1000 q / s (um baixo rendimento por padrões Redis ou memcached), eu diria que é mais provável que o seu problema esteja do lado do cliente (isto é, escolha da biblioteca do cliente, conexão/desconexão, etc ...), than with Redis server itself.

Finalmente, devo mencionar que, se gerar uma série de consultas Redis por pedido de HTTP, considere pipelining os comandos que envia para o Redis, tanto quanto possível. É realmente um ponto-chave para desenvolver aplicações Redis eficientes.

Se os seus servidores de aplicações estiverem na mesma caixa que o Redis, também poderá usar 'sockets' do domínio unix em vez do loopback TCP para se ligar ao Redis. Melhora ligeiramente o desempenho (até 50% mais capacidade quando a tubulação não é utilizada).

Verifique se o redis está a usar a memória de troca do sistema operativo. Se for então isso irá adicionar latência. Para descobrir, procure "latência induzida pela troca" aqui: http://redis.io/topics/latency

Se o seu 'hardware' do servidor for capaz de uma, é melhor começar a refazer o servidor com numactl. Não se esqueça de desligar o modo de recuperação da zona (vm.zone_ reclaim_ mode = 0) no sysctl se estiver a começar com o servidor redis com NUMA.

Tenta escrever que 300 são pedidos dentro de um guião de Lua. Ele deve estar trabalhando mais rápido porque você economiza tempo em contato com a pilha TCP/IP, mesmo que o código do seu cliente esteja rodando localmente para Redis.