Use os dois de uma vez em combinação. Atribuir algo na ordem de 1.000 conexões a um processo. Use um gerente para distribuir conexões e gerar novos processos se você chegar a um ponto em que todos os processos de manuseio atuais estão saturados.
Estou tentando projetar uma arquitetura para lidar com conexões de soquete TCP massivas e estou em dúvida sobre os limites dessa arquitetura.
Eu terei que lidar com conexões TCP ~ 20k simultâneas e essas são conexões de polling longo, elas permanecerão conectadas por longos períodos de tempo e estarão enviando dados a cada minuto.
O uso de threads está fora de questão, já que os threads de 20k irão prejudicar os recursos do sistema. Estou planejando usar gevent para lidar com essa quantidade de conexões simultâneas ou até mesmo usar haproxy e 2 servidores (com gevent) para lidar com 10k conexões cada um por exemplo. Isso faz sentido? Alguém tem algum conselho ou alguma experiência usando o gevent com conexões de 10K +? Alguém tem idéia dos requisitos de hardware para lidar com essas conexões? Eu vi alguns benchmarks que mostram muitos tempos de espera de conexão para gevent em 5k conexões simultâneas, o que não é muito promissor para o meu problema.
Nota : Eu já li sobre o problema C10k e os conselhos sobre o "Aplicativo Comet de um milhão de usuários".
Use os dois de uma vez em combinação. Atribuir algo na ordem de 1.000 conexões a um processo. Use um gerente para distribuir conexões e gerar novos processos se você chegar a um ponto em que todos os processos de manuseio atuais estão saturados.
Bem, como você pode usar 2 servidores para lidar com 10k cada, por que não usar 5 servidores e lidar com 4k cada?
Tags python haproxy long-polling