Óptima tamanho do buffer de fluxo de resposta de HttpWebResponse

Question

Qual é o tamanho do buffer ideal para usar com um fluxo de HttpWebResponse.GetResponseStream ()?

exemplos online variar de 256B para tanto quanto 5Kb. O que da? Eu acho que o tamanho do buffer pode ser situacional. Se assim o que são as situações de uso que tipo de tamanho do buffer?

Graças.

Answer 1

Na verdade, não importa muito.

Claro que, se você usar muito pequenos buffers, você pode ter que fazer algumas chamadas extras para baixo através das camadas para obter os bytes (embora o fluxo é provável fazendo pelo menos alguns buffer - Eu não sei o que é defaults estamos). E com certeza, se você usar realmente grandes buffers, você vai perder um pouco de memória e introduzir alguma fragmentação. Desde que você está, obviamente, fazendo IO aqui, a qualquer hora você ganha por aprimorando os buffers vai ser dominado pelo tempo IO.

Como regra geral, eu vou com uma potência de dois entre 2048 (2k) e 8192 (8k). Apenas certifique-se que você sabe o que está fazendo, se você ir com um tampão igual ou maior do que 85.000 bytes (é, em seguida, um "objeto grande" e sujeitos a diferentes regras GC ).

Na verdade, mais importante do que o tamanho do buffer é quanto tempo você segurá-la. Para objetos fora do heap de objeto grande, o GC é muito bom em lidar com objetos muito curta duração (Gen 0 coleções são rápidos) ou objetos muito longa vida (Gen 2). Objetos que vivem o tempo suficiente para chegar ao Gen 1 ou 2 antes de ser libertado são comparativamente mais caros, e, geralmente, muito mais vale o seu tempo se preocupando com que o tamanho do buffer é.

Uma nota final: se você acha que tem um problema de desempenho por causa do tamanho de buffers que você está usando, test isso. É improvável, mas quem sabe, talvez você tenha uma confluência ímpar de versão do sistema operacional, hardware de rede, e versão do driver que tem algum problema estranho com determinados porte buffers.

Answer 2

A minha experiência anedótica foi que ele realmente depende do que você está fazendo, mas tipicamente qualquer coisa na faixa de 1024-4096 bytes (1-4KB aka potência de dois) me daria um desempenho comparável (com 4KB de ser o " melhor número" Eu já vi).

Basicamente, você quer um grande o suficiente tampão para que não sejam desnecessariamente a leitura de dados a partir do fluxo, mas não tão grandes retornos diminuir. Se o buffer é muito grande (~ MBs), então você vai aumentar suas perdas de cache de memória, que pode realmente começar a diminuir o seu desempenho. Claro, isso varia muito com base na actual H / W (velocidade do barramento, o tamanho do cache, etc), mas eu parecem casos em que um buffer de 4MB foi mais lento do que o buffer de 4KB (ambos os casos tinham vidas longas, então GC não foi um problema).

Como Jonathan notas, testar a sua implementação atual antes de tentar otimizações prematuras.

Answer 3

Na verdade, eu estou tendo problema quando o tamanho do buffer é muito pequeno. Eu tenha testado e verificou-se que o tamanho do tampão não deve ser ajustado para ser pequeno valor. No meu exemplo eu defini-lo até 2048 eo download está se tornando muito lento em comparação com firefox um (firefox é sem baixar segmentação também, o mesmo que o meu).

E depois que eu defini-lo para um tamanho grande 409600, o download é muito mais rápido, eu acho que essa chamada extra vai custar sobrecarga ou de tal forma que faz o download lento. Talvez no nível de rede, o buffer é superior a seu tamanho do buffer, por isso a necessidade TCP pedir para reenviar o pacote de novo? (Apenas um palpite, como eu não sei como TCP funciona), tamanho do buffer no entanto pequena é definitivamente a abrandar o meu download. Eu testei-lo executando usando o Firefox download padrão (sem add on e segmenetation) e usando minha classe, ambos são muito diferentes.

Agora é muito mais rápido, cada vez que ele faz um loop, ele irá ler sobre 200000 bytes (200KB) como a conexão aqui é tranquila rápido, mas depois que eu estou correndo dois tópicos, ele vai muito mais lento, provavelmente precisará compartilhar com outro fio.