HttpWebRequest 和 HttpWebResponse 理想的异步缓冲区大小
我尝试在.NET 3.5中使用HttpWebRequest和HttpWebResponse，异步运行它们：BeginGetRequestStream、EndGetRequestStream、BeginWrite、EndWrite、BeginGetResponse、EndGetResponse、BeginRead、EndRead - 处理请求的所有部分都是异步的。
我有几个线程发送大量并发请求。 EndRead 和 EndWrite 都是阻塞操作 - 它们会阻塞当前线程，而对流的实际读/写完成，我试图为这些操作提出理想的输入/输出缓冲区大小。
我的推理是这样的：由于我一次有多个活动请求，它们将继续触发回调，让线程知道有一些数据可用或数据已发送。如果我的缓冲区很大，通过线路读取/写入数据将花费更长的时间，因此 EndRead/EndWrite 将阻塞更长时间。这将迫使同一线程上的其他请求等待更长的时间，因为它们的通知必须等待线程被解除阻塞。
所以，我的问题是，在这种情况下，合适的读/写缓冲区大小是多少。我原本以为每个 2048 字节，但我在各个博客中看到的一些示例代码显示了截然不同的值。
预先感谢您的任何想法。
I'm trying to use HttpWebRequest and HttpWebResponse in .NET 3.5, running them in asynchronously: BeginGetRequestStream, EndGetRequestStream, BeginWrite, EndWrite, BeginGetResponse, EndGetResponse, BeginRead, EndRead - all parts of handling a request are asynchronous.
I have a few threads that send a large number of concurrent requests. EndRead and EndWrite are both blocking operations - they block the current thread while the actual read/write against the stream is done, I'm trying to come up with an ideal input/output buffer size for these operations.
My reasoning is this: as I have multiple requests active at a time, they'll keep firing callbacks to let the thread know there's some data available or data was sent. If my buffers are large, reading/writing the data through the wire will take longer, so EndRead/EndWrite will block longer. This would force the other requests on the same thread to wait a bit longer, since their notifications will have to wait until the thread is unblocked.
So, my question is, what would be a good read / write buffer size in this situation. I was thinking 2048 bytes each, but some sample code I saw in various blogs show wildly different values.
Thanks in advance for any ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为更好的解决方案是不要过多担心缓冲区大小，但不要阻塞线程。如果您将委托传递给
Begin*方法的callback参数，则该回调将在操作完成时执行，您可以调用End*从那里，它将（几乎）立即返回。无需阻塞。关于缓冲区大小，如果它们对您确实很重要，您应该分析并找出最适合您的具体情况的内容。
I think a better solution would be not to worry about the buffer sizes too much, but don't block the threads. If you pass a delegate to the
callbackparameter of theBegin*methods, that callback is executed when the operation completes and you can callEnd*from there, which will (almost) immediately return. No blocking necessary.And regarding the buffer sizes, if they really matter to you, you should profile and find out what works best in your specific situation.
除了避免明显的极端值之外，对于应该设置的实际值没有明确的规则。这实际上取决于您要传输的数据类型以及数据量。您可能希望将写入缓冲区设置得相当高，但将读取缓冲区设置得较低。这是因为在这种情况下，写入（通常）比读取更昂贵。
在这种情况下，最好的办法是尝试一些值，看看它们的扩展效果如何。如有必要，您可以随时更改它们。
There's no definitive rule as to the actual values you should set, beyond avoiding the obvious extremes. It really depends on the type of data you're transfering, and how much of it there is. You probably want to set your write buffer quite high, but leave your read buffer lower. This is because writes are (usually) more expensive than reads when it comes to this kind of thing.
The best thing to do in this situation is try a few values and see how well they scale. You can always change them later if necessary.