Taxa de transferência; ajuda de planejamento de capacidade para C10K como design [duplicado]

Question

Estou projetando um serviço de rede no qual os clientes se conectam e permanecem conectados - o modelo não está muito longe do IRC menos as conexões do s2s.

Eu poderia usar alguma ajuda para entender como planejar a capacidade, em particular com os custos de recursos do sistema associados ao tratamento de mensagens de / para clientes.

Há um artigo que tentou obter 1 milhão de clientes conectados ao mesmo servidor [1]. Naturalmente, a maioria desses clientes estava completamente ociosa no teste. Se os clientes enviassem uma mensagem a cada 5 segundos ou mais, o sistema certamente seria colocado de joelhos.

Mas ... Como você faz menos acenos de mãos e sabe, medir esse ponto de ruptura?

Estamos falando de mensagens sendo enviadas por um cliente através de um soquete TCP, no kernel e lidas por um aplicativo. Os dados são embaralhados na memória de um buffer para outro. Preciso considerar o rendimento da memória ("5 GT / s" [2], etc.)?

Tenho certeza que tenho a capacidade de medir os requisitos básicos de memória devido a buffers TCP / IP, largura de banda esperada e recursos de CPU necessários para processar mensagens. Eu sou um pouco ofuscado no que estou chamando de "throughput".

Ajuda!

Além disso, alguém realmente faz isso? Ou, a maioria das pessoas acena e vê o que o mundo real oferece, e então reage apropriadamente?

[1] link

[2] link

    

Answer 1

We're talking about messages being sent by a client over a TCP socket, into the kernel, and read by an application. The data is shuffled around in memory from one buffer to another.

Não, não é. Não se você fizer isso corretamente de qualquer maneira. Para Linux, você deve procurar as chamadas do sistema sendfile (2) e splice (2). Outros kernels provavelmente têm instalações similares de cópia zero, mas o AFAIK não foi padronizado.

Na prática, melhor escrever o programa para ser o mais simples possível, medir onde é o gargalo, melhorar, medir, melhorar ... Prevendo gargalos é difícil e prematura otimização é a raiz de todos os males (como disse Knuth) .