由于不熟悉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中设置连接数和代理服务器的设置，而不需要在程序中硬编码了。
PS：最近用Visual Studio，用C#，不知道仍然是先入为主的习惯问题，总觉得没有使用Eclipse编写Java好用，首先是自己对代码编写的快捷键不熟悉，所以效率要慢一半
为什么不能用源码绑定到dll上，就像在eclipse里把src绑定到jar包上一样
为什么就没有一个快捷键全部快速自动导入命名空间呢
为什么就没有一个Ctrl+O，快速定位到类或者资源呢，不要跟我说Ctrl+,，把方法，类，字段啥都混在一起了
最后经过了一番搜索，发现了有个Visual Studio的插件，Productive PowerTools，可以增强有些特性，比如使用Alt+Up上移一行代码，Alt+Down下移当前行代码，这跟在Eclipse中的操作习惯一致了，不过这并没有自动把移动的代码格式化，这是Eclipse要强大的地方。
光子：经测试，config的配置项是可用的。