注意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要强大的地方。

 

光子:经测试,config的配置项是可用的。

 

from:http://blog.sina.com.cn/s/blog_3eea4f680100s48d.html