C#多线程环境下调用 HttpWebRequest 并发连接限制

HttpClient是否有默认并发数限制？

在.Net 4.0之前，一直是依靠HttpWebRequest实现Http操作的。它默认有一个非常保守的同一站点下最大2并发数限制，导致默认情况下HttpWebRequest往往得不到理想的速度（估计这个策略郁闷了不少码农），必须修改App.config或ServicePointManager.DefaultConnectionLimit的值。

MS在.Net 4.5中引入了一个HttpClient类专门处理Http操作，本来我以为HttpClient和HttpWebRequest遵循一样的策略的。今天在写一个多线程下载的程序的时候，用到了10个并发连接，发现在默认的情况下，HttpClient并没有并发数限制。

最初我以为是.Net 4.5取消了这个并发数限制（毕竟现在基本上没有谁遵循这个标准了），然后用WebRequest重写了相关代码，发现依然是2并发上限，并且ServicePointManager.DefaultConnectionLimit的值也是2。也就是说： HttpClient不受HttpWebRequest并发策略控制，也没有系统级的并发限制。

另外，测试的时候发现，HttpWebRequest默认也不是对所有地址都2并发上限的。例如，对本地的http地址连接（http://localhost/*）就没有并发限制。

 

C#多线程环境下调用 HttpWebRequest 并发连接限制

.net 的 HttpWebRequest 或者 WebClient 在多线程情况下存在并发连接限制，这个限制在桌面操作系统如 windows xp , windows 7 下默认是2，在服务器操作系统上默认为10. 如果不修改这个并发连接限制，那么客户端同时可以建立的 http 连接数就只有2个或10个。对于一些诸如浏览器或网络蜘蛛的应用，2个或10个并发数量实在太少，大大影响应用的性能。之所以有这个并发连接限制，是因为 http 1.0 和 http 1.1 标准规定并发连接数最大为2. 不过目前主流的浏览器都已经不遵循这个规则了，但 .net framework 依然默认遵循这个规则。

很多文章说用异步方式访问 HttpWebRequest 可以提高并发性能，但我测试下来，如果不修改这个默认并发连接数，同步或异步方式访问性能都很不好。

调整这个默认并发连接限制的方法很简单

只要在程序中设置：

System.Net.ServicePointManager.DefaultConnectionLimit = 512;

这个值最好不要超过1024。

我们也可以在app.config 中对最大并发连接数进行设置，方法如下：

<configuration>
<system.net>
<connectionManagement>
<add address = "http://www.google.com" maxconnection = "512" />
<add address = "*" maxconnection = "512" />
</connectionManagement>
</system.net>
</configuration>

修改了这个设置后，并发性能明显提高，从原来每秒钟20次直接上升到每秒钟1000多次。

 

 

 

注意DotNet的ConnectionLimit

 

由于不熟悉C#的开发，在做一个系统WS接口的压力测试时走了弯路。发现这个问题的原委是要在用C#压力测试我们的一个REST Web Service.服务器上我理论预计的性能是100并发，4s内响应完成。这个系统提供了给DotNet的客户端，使用hammock库编写而成，在压力测试中，系统性能总是上不来，在查看服务器日志后发现请求都是串行处理的，所以维持了400ms每个请求的性能水平，而理论上的十个通道的并行处理的性能没有达到。我开始以为是否是同事编写的客户端有问题，检查之后发现没有任何问题；转而寻求是否是Hammock库的问题，未果。然后怀疑服务器的问题，我使用Java，restclient库编写了一个测试程序，发现10个通道全部启用，达到了理论性能，服务器方面完成不成问题。所以应该是C#方面的问题，Hammock的源码比较复杂，看了半天也没啥发现，在我们的这个RestClient中有点杀鸡用牛刀的感觉，是否是其中的什么Bug呢？所以准备自行编写客户端。由于服务器上使用Rest，XML传输格式的XSD文件也已经生成，客户端上都是使用xsd文件反向生成的POCO对象，查了一下C#的文档，直接使用XmlSerializer就可以很方便的实现序列化和反序列化了。并且System.Net命名空间中有HttpWebRequest类，很容易自行实现自己的客户端，而不是用hammock库，这样就可以排除hammock的问题。昨晚自己写了一下，一测试性能还是无法达到，使用netstat查看连接，居然发现同时还只有两个连接到服务器。觉得奇怪，所以使用C# Socket Connection limit之类的关键字Google，原来C#类库中，HttpWebRequest默认的最大连接数为2，为什么是个二呢？想不通，其实我觉得既然作为类库，C#完全不必要限制客户端的连接数，这是由程序员控制的啊。有两个办法设置不同的连接数。

1. HttpWebRequest.ServicePoint.ConnectionLimit

2. ServicePointManager.DefaultConnectionLimit

任意设置一个到我的最大并行处理数，比如时，性能马上就上去了，几乎逼近于理论性能，但是相比使用Java测试的结果还是要整体慢3s左右，因为不知道什么原因，在首次连接服务器时，会有一个几秒的延迟。不知道具体原因是什么，是否又有什么默认设置？又经过了一番搜索和研究，终于发现了真正的原因，在使用HttpWebRequest类的时候，默认会去检查代理服务器设置，这样当然就慢了。而且可以在app.config中设置连接数和代理服务器的设置，而不需要在程序中硬编码了。

  <system.net>

    <defaultProxy enabled="false">

      <proxy/>

      <bypasslist/>

      <module/>

    </defaultProxy>

    <connectionManagement>

      <add address="*" maxconnection="10"/>

    </connectionManagement>

  </system.net>

PS：最近用Visual Studio，用C#，不知道仍然是先入为主的习惯问题，总觉得没有使用Eclipse编写Java好用，首先是自己对代码编写的快捷键不熟悉，所以效率要慢一半

为什么不能用源码绑定到dll上，就像在eclipse里把src绑定到jar包上一样

为什么就没有一个快捷键全部快速自动导入命名空间呢

为什么就没有一个Ctrl+O，快速定位到类或者资源呢，不要跟我说Ctrl+,，把方法，类，字段啥都混在一起了

最后经过了一番搜索，发现了有个Visual Studio的插件，Productive PowerTools，可以增强有些特性，比如使用Alt+Up上移一行代码，Alt+Down下移当前行代码，这跟在Eclipse中的操作习惯一致了，不过这并没有自动把移动的代码格式化，这是Eclipse要强大的地方。