Оптимальный размер буфера для потока ответов HttpWebResponse

Question

Какой оптимальный размер буфера для использования с потоком из HttpWebResponse.GetResponseStream ()?

Онлайн-примеры варьируются от 256 до 5 КБ. Что дает? Я предполагаю, что размеры буфера могут быть ситуативными. Если да, то в каких ситуациях использовать размер буфера?

Спасибо.

Answer 1

Действительно, это не имеет большого значения.

Конечно, если вы используете действительно небольшие буферы, вам, возможно, придется сделать несколько дополнительных вызовов вниз по слоям, чтобы получить байты (хотя поток, вероятно, выполняет хотя бы некоторую буферизацию - я не знаю, какие у него значения по умолчанию) являются). И конечно, если вы используете действительно большие буферы, вы потратите немного памяти и внесете некоторую фрагментацию. Поскольку вы явно делаете IO здесь, в любое время, когда вы получаете выгоду от настройки буферов, будет доминировать время IO.

Как правило, я иду с силой два между 2048 (2k) и 8192 (8k). Просто убедитесь, что вы знаете, что делаете, если у вас есть буфер, равный или превышающий 85 000 байт (это тогда "большой объект" и подчиняется другим правилам GC ).

На самом деле, более важным, чем размер буфера, является то, как долго вы его держите. Для объектов вне кучи больших объектов GC очень хорошо справляется с очень короткоживущими объектами (коллекции Gen 0 быстрые) или с очень долгоживущими объектами (Gen 2). Объекты, которые живут достаточно долго, чтобы добраться до Быт 1 или 2 перед освобождением, сравнительно более дороги и, как правило, стоят гораздо больше времени, чем беспокойство, чем размер буфера.

Последнее замечание: если вы думаете, что у вас проблемы с производительностью из-за размера используемых вами буферов, проверьте его. Это маловероятно, но, кто знает, может быть, у вас странное слияние версии ОС, сетевого оборудования и выпуска драйверов, что имеет некоторую странную проблему с буферами определенного размера.

Answer 2

Мой неподходящий опыт показывает, что это действительно зависит от того, что вы делаете, но обычно все, что находится в диапазоне 1024-4096 байт (1-4КБ или два), даст мне сравнимую производительность (с 4КБ " лучший "номер, который я видел).

По сути, вы хотите, чтобы буфер был достаточно большим, чтобы вы не бесполезно считывали данные из потока, но не настолько велики, чтобы уменьшить отдачу. Если ваш буфер слишком велик (~ МБ), то вы увеличите потери в кеше памяти, что может привести к снижению производительности. Конечно, это сильно варьируется в зависимости от фактического H / W (скорость шины, размер кэша и т. Д.), Но мне кажется, что случаи, когда буфер 4 МБ был медленнее, чем буфер 4 КБ (оба случая имели длительный срок службы, поэтому GC вопрос).

Как отмечает Джонатан, протестируйте текущую реализацию, прежде чем пытаться преждевременной оптимизации.

Answer 3

На самом деле у меня проблема, когда размер буфера слишком мал. Я проверил и проверил, что размер буфера не должен быть маленьким. В моем примере я установил его на 2048, и загрузка становится ОЧЕНЬ МЕДЛЕННОЙ по сравнению с Firefox One (Firefox One тоже без сегментации загрузки, как и у меня).

И после того, как я установил большой размер 409600, загрузка стала НАМНОГО БЫСТРЕЕ, я думаю, что дополнительный вызов будет стоить непроизводительных затрат или около того, что замедляет загрузку. Возможно, на сетевом уровне буфер превышает ваш размер буфера, поэтому TCP должен запросить повторную отправку пакета? (Просто предположение, поскольку я не знаю, как работает TCP), однако небольшой размер буфера определенно замедляет мою загрузку. Я проверил его, запустив с использованием Firefox загрузку по умолчанию (без добавления и сегментации) и используя мой класс, оба они слишком разные.

Теперь это намного быстрее, каждый раз, когда он зацикливается, он будет считывать около 200000 байт (200 КБ), поскольку соединение здесь очень быстрое, но после того, как я запускаю два потока, оно будет работать намного медленнее, возможно, потребуется поделиться с другим нить.