Chinaunix首页 | 论坛 | 博客
  • 博客访问: 847842
  • 博文数量: 366
  • 博客积分: 10267
  • 博客等级: 上将
  • 技术积分: 4290
  • 用 户 组: 普通用户
  • 注册时间: 2012-02-24 14:04
文章分类

全部博文(366)

文章存档

2012年(366)

分类: 系统运维

2012-03-23 20:52:03

 其实在.net socket编写高性能稳定方面的资料真的比较少,一个实质性的测试数据结果对比就更少了.我们可以从看到MS说net 2.0 sp1后的socket通讯能力非常强劲,可以同时挂起6W个IO(可以简单地认为可以在一秒内send+receive可以达到6W或更高),但要找这个数据的测试似乎很难.但在一篇MS关于WCF的性能测试中基于tcp部署的性能在一台4路服务器中可以达到这个量().那WCF可以达到那基于c# socket实现达到这样的IO处理能力应该完成没问题.经常一段时间的努力即使在一台core e4300 5年前的PC上完全胜任每秒6W IO的处理能力,还包括数据接收,协议分析对像序列化写入.

以下是一些经验总结:

Buffer Pool

这个相信不用说,MSDN上也介绍这种用法.但如何分配这个buffer大小呢?我们一般会一条消息用一个buffer,这个时候我们就很难分配了,不得不按最大消息长度来定义buffer长度,这样做从内存分配上来说是极其不合理的.不过现在内存多不用计较(也许).但还存在一种问题就是send的时候一般针对buffer的,当消息小的时候就不得不按消息的数量来操作IO,如果buffer的灵活性更好如小的消息可以多个写入一个buffer,大的消息可以写入几个buffer.这样即能达到内存使用合理.也能控制最少的IO处理最多的信息达到更好的性能.

SocketAsyncEventArgs池需要吗?

这个MSDN上也有介绍这种用法,但就存在一个如何分配的问题,连接产生的时候分配,连接断开的时候回收?如果是这个SAEA怎样分配buffer大小(别轻易地使用SetBuffer(byte[],int,int)方法);不得不面对以上Buffer说的问题.所以SEAE和Buffer Pool一样大小来分配池结合使用,用的时候拿用完回收到池. 其实SEAE最好是和BUFFER整合在一起,这样做的好处就是在高并发的时候可以节省大量的byte[] Copy.

队列的使用

  队列的使用就是更好控制线程处理数据,既然一个线程就能更好地完成工作,可必要用更多的线程去做呢.记住用最少的线程完成最多的事情.

在运行期内你能做到最少化内存分配吗?

  你能让一些getByes方法不产生new byte[]吗?好好看下MSDN相关对像方法看有什么途径来达到这种效果.

不于过于自信多用些分析工具

  也许你有着很多年的经验,也用一些计时器来衡量过代码的执行行性能.但有时候你真的很难发现原来性能并不存在于你测的地方.不要只关注于代码的CPU执行时间,别忘了.NET下还有一个巨头GC.用性能分析工具分析代码的执行时间同时,不要忘了分析一下代码在某些情况下的内存分配情况.VS2010就提供了这些方便的分析工具.

以下是这段时间优化的测试情况

测试结果一:

1K连接分别获取一个对像和一个列表对像

单一对像信息

class GetResponse : IMessage { public User User; public void Save(BufferWriter writer) } class User : IMessage { public string Name; public string EMail; public string City; public string Counrty; public void Save(BufferWriter writer) { writer.Write(Name); writer.Write(EMail); writer.Write(City); writer.Write(Counrty); } public void Load(BufferReader reader) { Name = reader.ReadString(); EMail = reader.ReadString(); City = reader.ReadString(); Counrty = reader.ReadString(); } }

列表对像信息(5条)

class Response : IMessage { private IList mOrders = new List(); public IList Orders { get { return mOrders; } } } class Order : IMessage { public int OrderID; public string CustomerID; public int EmployeeID; public long OrderDate; public long RequiredDate; public string ShipName; public string ShipAddress; public string ShipCity; public string ShipRegion; public string ShipPostalCode; public string ShipCountry; public void Save(BufferWriter writer) { writer.Write(OrderID); writer.Write(CustomerID); writer.Write(EmployeeID); writer.Write(OrderDate); writer.Write(RequiredDate); writer.Write(ShipName); writer.Write(ShipAddress); writer.Write(ShipCity); writer.Write(ShipRegion); writer.Write(ShipPostalCode); writer.Write(ShipCountry); } public void Load(BufferReader reader) { OrderID = reader.ReadInt32(); CustomerID = reader.ReadString(); EmployeeID = reader.ReadInt32(); OrderDate = reader.ReadInt64(); RequiredDate = reader.ReadInt64(); ShipName = reader.ReadString(); ShipAddress = reader.ReadString(); ShipCity = reader.ReadString(); ShipRegion = reader.ReadString(); ShipPostalCode = reader.ReadString(); ShipCountry = reader.ReadString(); } }

测试结果

测试结果2:

由于局域网带宽限制,所以只能测试2K和3K连接下的单一对象获取

除了以上测试结果外,还进行了同场景500物体状态变更广播,在core e4300也完全能胜任,每秒转发50W的消息量.每个client的消息延时在100ms以内.

同场景物体广播测试程序: (想测试效果请分开电脑运行,如果你的网络是100mb的话最大只能运行5个client,如果服务器的cpu低于core e4300也有可能支持不了500同屏)

阅读(630) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~