Qual intervalo é considerado seguro para conexões / GETS / SETS por segundo por instância do servidor com o memcached?

Question

Pergunta

Estou interessado em aprender as seguintes métricas, por instância do memcached:

• Intervalo seguro para conexões / GETs / SETs por segundo
• Limite superior para conexões / GETs / SETs por segundo

Tenho a sensação de que o verdadeiro gargalo serão as conexões, mas gostaria de receber informações de pessoas que estabeleceram instalações do memcached em seus sites.

Antecedentes

Eu gerencio um site que exibe centenas de milhões de visualizações de páginas ao longo de um mês. Ele é distribuído entre vários servidores da web. O site foi originalmente codificado com um esquema em cache baseado em arquivo que não foi compartilhado pelo pool de servidores da Web; cada servidor da Web manteve sua própria cópia em cache de cada página.

Por razões óbvias, estamos migrando para o memcached. Nós convertemos nossas páginas de tráfego mais baixo, mas mais dinâmicas (também conhecidas como "páginas com taxas de acesso ao cache mais baixas") sem problemas. Passamos agora para as nossas páginas de tráfego mais alto, mas mais estáticas (também conhecidas como "páginas que devem ter taxas de acertos de cache mais altas"). Nós convertemos os de tráfego mais baixo primeiro e já vimos um salto de 3.5k GETs por segundo em média para 11k GETs por segundo em média. Estamos vendo entre 400-600 conexões ativas a qualquer momento, em média. Nosso limite de conexão está definido para 4k em nosso arquivo de configuração.

Considerando que ainda temos as páginas de tráfego mais alto a serem implementadas, esse pareceu um bom momento para pesquisar os intervalos aceitos e os limites superiores em relação ao memcached. Dessa forma, podemos determinar se precisamos expandir para instâncias adicionais do memcached antes de movermos as partes com o tráfego mais alto do nosso site para o memcached. Eu percebo que nosso uso agora não é motivo para alarme, mas eu gostaria de saber quando será, e gostaria de saber isso antes.

    

Answer 1

Um número de conexões simultâneas é mais importante que um número de GETs / SETs da minha experiência. Eu estou olhando agora para um gráfico histórico do Cacti, o gráfico informa que a instância do memcached recebeu cerca de 4 milhões de acessos por segundo no máximo (2.8M GETs e 1.2M SETs). Eu duvido que esses números sejam reais. Eles foram alcançados usando apenas uma conexão ativa de qualquer maneira. O problema foi que, quando enfatizei testar essa configuração usando uma ferramenta de teste de carga de um site, o memcached começou a consumir CPU em apenas 2-3K acessos por segundo. Eu tive que construir uma fazenda de memcacheds para distribuir a carga. Como você pode ver, existe uma relação não linear entre o número de conexões simultâneas e o número de acessos por segundo que o memcached pode manipular. O Memcached parece começar a degradar rapidamente em um certo número de conexões simultâneas, você realmente precisa enfatizar o teste de sua configuração para determinar este número crítico.

    

Answer 2

Talvez a melhor maneira de examiná-la seja ver sua limitação no desempenho interagindo com o memcached. Alguns scripts para determinar o tempo médio de resposta no dia normal seriam um bom ponto de partida.

Na sua pergunta principal:

Eu acho que, em geral, a quantidade de atividades simultâneas (gets / sets) irá variar em sua configuração de hardware de qualquer maneira, então quaisquer respostas sobre isso seriam subjetivas. Acho que encontrar uma maneira melhor de medir o sucesso em relação ao seu próprio ambiente é ir direto ao ponto. Como observado, o teste de estresse é naturalmente muito importante nesse processo.

Felicidades

    

Answer 3

Não existe uma fórmula mágica para prever a capacidade - você precisa fazer isso por meio de experimentação e análise numérica.

we've already seen a jump from 3.5k GETs per second on average to 11k GETs per second on average

Se você está dizendo que esse é o resultado da implementação da alteração, isso significa que você estava perdendo 2 terços do seu tráfego devido a problemas de desempenho?

Embora essas métricas sugiram que você consiga atender mais tráfego com menos hardware, você mediu o efeito nos tempos de resposta? Usando simulação de rede apropriada?

Você precisa planejar uma arquitetura que permita controlar o que e onde o armazenamento em cache é feito - você deseja distribuir facilmente a carga entre várias instâncias do memcached com alguma capacidade de failover. Isso fica muito complicado, muito rapidamente - que é uma das razões que tendem a deixar memcached até um último recurso - e nunca para um cache front-end. As outras razões são que, onde testei, há ganhos insignificantes em comparação com outros métodos de compartilhamento de dados (proxies reversos na frente, bom ajuste no meio e armazenamento compartilhado distribuído no back end). Mas estou muito consciente de que a arquitetura precisa refletir os componentes usados para construir o sistema - minha experiência é principalmente com sistemas do tipo LAMP de escala média - mas o modelo com uma camada de servidor de aplicativos dividida é muito diferente.