.NET没有可靠的异步套接字通信?
我曾经在.NET中写过一个Crawler。 为了提高其可伸缩性,我尝试利用.NET的异步API。
System.Net.HttpWebRequest具有异步API BeginGetResponse / EndGetResponse。 但是,这对API只是为了获取HTTP响应头和Stream实例,我们可以从中提取HTTP响应内容。 所以,我的策略是使用BeginGetResponse / EndGetResponse来异步获取响应Stream,然后使用BeginRead / EndRead从响应Stream实例异步获取字节。
在Crawler进行压力测试之前,一切看起来都很完美。 在压力测试下,Crawler遭受高内存使用。 我用WinDbg + SoS检查了内存,并说明System.Threading.OverlappedData实例有很多字节数组。 经过一些互联网搜索后,我从微软发现了这个KB https://support.microsoft.com/kb/947862 。
根据KB,异步I / O的数量应该具有“上限”,但它不会告诉“建议的”绑定值。 所以,在我看来,这个KB没有任何帮助。 这显然是一个.NET错误。 最后,我不得不放弃从响应Stream中异步提取字节的想法,并且只是以同步方式进行。
允许带有点网络套接字的异步IO的.NET库(Socket.BeginSend / Socket.BeginReceive / NetworkStream.BeginRead / NetworkStream.BeginWrite)必须具有其异步IO的未完成缓冲区(发送或接收)数量的上限。
网络应用程序应该具有其发布的未完成异步IO数量的上限。
编辑:添加一些问号。
任何人都有在Socket和NetworkStream上进行异步I / O的经验吗? 一般来说,生产中的爬虫是否通过同步或异步的互联网进行I / O操作?
Hmya,这不是.NET框架问题。 链接的知识库文章本来可能更明确一点:“你正在使用一把装满的枪,当你瞄准你的脚时会发生这种情况”。 该枪中的子弹是.NET,使您能够启动尽可能多的异步I / O请求。 它会做你要求它做的事情,直到你遇到某种资源限制。 在这种情况下,可能在第0代堆中有太多固定的接收缓冲区。
资源管理仍然是我们的工作,而不是.NET。 它与没有绑定的内存分配没有什么不同。 解决此特定问题需要限制未完成的BeginGetResponse()请求的数量。 有数百个没有意义,他们每个人都必须一次挤过Intertube。 添加另一个请求只会导致完成时间更长。 或者崩溃你的程序。
您显然希望限制并发请求的数量,无论您的爬虫是同步还是异步。 这个限制是不固定的,这取决于你的硬件,网络,……
我不太确定你的问题是什么,因为HTTP /套接字的.NET实现是“好的”。 有一些漏洞(请参阅我关于正确控制超时的post ),但它完成了工作(我们有一个生产爬虫,每秒可以获取数百页)。
顺便说一句,我们使用同步IO,只是为了方便起见。 每个任务都有一个线程,我们限制并发线程的数量。 对于线程管理,我们使用Microsoft CCR 。
这不仅限于.Net。
这是一个简单的事实,每个异步请求(文件,网络等)都使用内存和(在某些时候,至少是网络请求)非页面缓冲池(有关非托管代码中可能遇到的问题的详细信息,请参阅此处 )。 因此,未完成请求的数量受内存量的限制。 在Vista之前有一些非常低的非页面缓冲池限制会在内存不足之前导致问题,但在后vista环境中,非页面缓冲池使用情况要好得多(参见此处 )。
它在托管代码中要复杂一点,因为除了在非托管世界中遇到的问题之外,还必须处理这样一个事实,即用于异步请求的内存缓冲区会被固定,直到这些请求完成为止。 听起来你在读取方面遇到了这些问题,但是对于写入来说就差一点,如果不是更坏的话(一旦TCP流控制开始连接,那么发送完成将开始花费更长的时间,因此这些缓冲区固定的时间越来越长 – 见这里和这里 )。
问题不在于.Net异步的东西是破坏的,只是抽象是这样的,它使它看起来比实际上更容易。 例如,要避免固定问题,请在程序启动时将所有缓冲区分配到单个大型连续块中,而不是按需分配…
就个人而言,我会在非托管代码中编写这样的爬虫,但那只是我;)你仍然会遇到很多问题,但是你可以对它们有更多的控制权。
没有KB文章可以给你一个上限。 上限可以根据可用的硬件而有所不同 – 对于具有16g内存的机器,2G内存机器的上限将是不同的。 它还取决于GC堆的大小,碎片的碎片程度等。
您应该做的是使用信封计算后面的公制。 计算出每分钟要下载的页数。 这应该确定您想要多少异步请求(N)。
一旦你知道N,就创建一段代码(比如生产者 – 消费者管道的消费者端),它可以创建N个未完成的异步下载请求。 一旦请求完成(由于超时或由于成功),通过从队列中拉出工作项来启动另一个异步请求。
您还需要确保队列不会超出边界,例如,无论出于何种原因,下载都会变慢。
当您使用套接字的异步Send(BeginSend)方法时会发生这种情况。 如果你使用自己的自定义线程池,并通过线程发送数据同步发送方法主要是解决这个问题。 经过测试和certificate。
上述就是C#学习教程:.NET没有可靠的异步套接字通信?分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/1269736.html