Estou trabalhando em um site com tráfego relativamente alto (>150 mil visualizações de página/dia). Estou recebendo alguns erros 429, principalmente no message bus. Anteriormente, tive alguns problemas devido a uma má configuração de set_real_ip_from, mas isso já foi resolvido. Também removi (talvez temporariamente?) o template de limitação de taxa.
Ainda estou vendo cerca de 0,5 erro 429 por segundo.
Tenho 5 workers do Unicorn com uma CPU de 2 núcleos/4 threads. 16 GB de RAM. O Postgres está em um host separado. As CPUs permanecem com mais de 50% de ociosidade.
Removi o template de limitação de taxa e aumentei os workers do Unicorn para 5 por volta das 8:20.
Isso é completamente normal. O message-bus irá reduzir a frequência com o código 429, pois seus unicórnios estão sob carga pesada e fazendo uma pequena fila.
4 núcleos com 16 GB de RAM é uma proporção realmente estranha se o nó não estiver executando o banco de dados. 8/8 seria melhor, por exemplo.
Ótimo! Obrigado. A CPU ainda está sobrecarregada com o processamento de imagens, o que, espero, deve ser resolvido em um ou dois dias.
Verdade. Mas o hardware dedicado tem 2 núcleos/4 threads. É fácil adicionar RAM, não núcleos (tenho outro em casa com 32 GB!). Separei o banco de dados e a web em duas máquinas para obter mais CPU. Tenho meia dúzia de outros bancos de dados de sites de baixo tráfego no mesmo servidor de banco de dados (web em outro host). Você acha que seria melhor executar apenas o banco de dados e a web na mesma máquina? Perderia um pouco de CPU, mas melhoraria a latência, imagino.
Se você tiver capacidade de balanceamento de carga aqui, então você pode tentar colocar os workers da web em ambas as máquinas para seu site de alta carga, com menos na que tem o banco de dados, talvez 5+2?
Se resolver o problema com dinheiro for uma opção, basta conseguir outro host com uma melhor proporção CPU:RAM.
Bem, essas máquinas que consegui de graça estão ficando um pouco velhas, então estou começando a aceitar isso — embora o desempenho de CPU única ainda pareça melhor que o de um DO Droplet. Se resolver o problema com dinheiro a curto prazo fosse uma opção, provavelmente eu não teria esse cliente específico que quer desempenho empresarial a preços de negócio.
Mas também percebi que havia o número de unicórnios hard-coded em outro lugar da cadeia, então ainda estou rodando apenas 3.
Infelizmente, minha configuração atual só se comunica com o Docker em um único host. Deveria dedicar um pouco mais de tempo para ver se consigo colocar alguns unicórnios na outra máquina também. Provavelmente é hora de dar uma olhada no HAproxy novamente, mas tenho outro projeto que realmente quero lançar primeiro.
Muito obrigado pela sua contribuição.
EDIT: E quando finalmente passei de 3 para 5 unicórnios, os gráficos de desempenho ficaram mais ou menos os mesmos (talvez um pouquinho mais lentos?), mas os erros 429 caíram significativamente. Parece que, uma vez que o processamento de imagens for concluído, tudo vai funcionar muito bem.
E, apenas um dia depois, os erros 429 caíram para quase zero, então o conselho de Rafael de “simplesmente não se preocupe” foi brilhante! Obrigado novamente, Kane e Rafael. Não posso exagerar o quanto agradeço pela ajuda de vocês.
