httpwebresponse响应流的最佳缓冲区大小

真的,没什么关系。

当然,如果使用非常小的缓冲区,那么可能需要通过层进行一些额外的调用来获取字节(尽管流可能至少进行了一些缓冲——我不知道它的默认值是什么)。当然,如果使用真正大的缓冲区,会浪费一些内存并引入一些碎片。因为很明显你在这里做IO,任何时候你通过调整缓冲区获得的时间都会被IO时间控制。

一般来说,我在2048(2K)到8192(8K)之间使用2的幂。只要确保你知道你在做什么,如果你使用一个等于或大于85000字节的缓冲区(它是一个 "large object" and subject to different GC rules )

事实上,比缓冲区大小更重要的是保存它的时间。对于大型对象堆之外的对象,GC非常擅长处理非常短的对象(gen 0集合速度很快)或非常长的对象(gen 2)。如果对象的寿命足够长,可以在释放之前到达第1代或第2代,那么它的成本相对更高,而且通常比缓冲区有多大更值得您花时间去担心。

最后一个注意事项:如果您认为由于所使用的缓冲区的大小而导致性能问题, 测试 它。这是不太可能的,但是谁知道呢,也许你有一个奇怪的集合,操作系统版本,网络硬件和驱动程序版本,有一些奇怪的问题与某些大小的缓冲区。

我的轶事经验是,它确实取决于你在做什么,但通常在1024-4096字节(1-4kba.k.a.2的幂)范围内的任何东西都会给我相当的性能(4kb是我见过的“最佳”数字)。

基本上,您需要一个足够大的缓冲区,这样您就不会不必要地从流中读取数据,但不会太大,这样会降低返回值。如果缓冲区太大(~mbs),则会增加内存缓存未命中,这实际上可能会开始降低性能。当然,这根据实际的H/W(总线速度、缓存大小等)变化很大,但我认为4MB缓冲区比4KB缓冲区慢(这两种情况的生存时间都很长,所以GC不是问题)。

正如Jonathan所指出的,在尝试过早的优化之前测试当前的实现。

实际上,当缓冲区太小时,我遇到了问题。我已经对它进行了测试,并验证了缓冲区大小不应该设置为较小的值。在我的示例中,我将其设置为2048,与firefox one相比,下载速度变得非常慢(firefox one也没有下载分段,与我的一样)。

当我把它设置为一个大尺寸409600后,下载速度会快得多,我认为额外的调用会花费开销,或者使下载速度变慢。也许在网络级别,缓冲区超过了您的缓冲区大小,所以TCP需要再次请求重新发送包吗?(只是一个猜测,因为我不知道TCP是如何工作的),不管缓冲区大小有多小,都会减慢我的下载速度。我已经通过使用firefox默认下载(没有附加组件和segmenuetation)和使用我的类测试了它,两者都有很大的不同。

现在速度快得多,每次循环,它将读取大约200000字节(200kb),因为这里的连接是安静快速的,但是在我运行两个线程之后,它将慢得多,可能需要与另一个线程共享。