并发Web请求性能问题

Question

我正在开发一项新服务,为我们公司的多个Web属性运行QA,并遇到了一个有趣的网络并发问题.为了提高性能,我使用TPL从大量url创建HttpWebRequests,以便它们可以并行运行; 但是,我似乎无法找到过程中的瓶颈所在.

我到目前为止的观察:

• 我可以通过TPL获得最多约25-30个并行线程
• CPU永远不会破坏5-6%的服务(运行在1-4核心,有和没有H/T)
• NIC使用率从未突破2-3%
• 整体网络流量似乎没有受到影响(其他用户不抱怨,速度测试运行的同时不会显示太多影响)
• 在办公室网络(15Mbps)或我们的数据中心(100 + Mbps)上运行之间的速度变化不大
• 通过一次从多个主机下载而不是从一个主机上下载大量页面,我获得了一点性能提升.

可能的痛点:

• CPU(内核或硬件线程数)
• NIC
• 允许的最大并发HttpWebRequests数
• LAN
• 广域网
• 路由器/交换机/负载平衡器

所以问题是:

显然现在可以在几分钟内下载整个互联网,但我很想知道在这样的场景中瓶颈在哪里以及可以采取什么措施来克服它.

作为旁注,我们目前正在使用第三方服务进行抓取,但我们在某些方面受到限制,并希望获得更大的灵活性.关于企业秘密酱或箭头尖端的毒药 ...... :)

Answer 1

我强烈怀疑以下是其中一个原因:

1. 您正在运行默认连接限制.检查ServicePointManager.DefaultConnectionLimit的值.我建议你把它设置为几乎无限的值,比如1000.
2. TPL没有启动尽可能多的线程来使网络饱和.请注意,远程Web服务器可能会有大量延迟.等待时,您的线程不会在网络上加载负载.

TPL不保证您有任何最低并行度(DOP).这很遗憾,因为有时你真的需要在使用IO时完全控制并行度.

我建议您手动启动固定数量的线程来执行IO,因为这是保证特定DOP的唯一方法.您需要尝试确切的值.它可以在50到500的范围内.您可以减少线程的默认堆栈大小以节省具有该多个线程的内存.