IOCP服务端框架(含调用源代码例子)重新设计后,性能提升的难以相信,稳定性也很靠谱,聊聊我的设计思路吧!

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/yongliliu/article/details/6692250

一,设计思路
1、设计模式;
      IO收发线程与EMPLOY任务线程必须分离设计,否则如果只考虑IO线程来处理所有事情的话,一旦出现某个业务接口运行较慢,势必造成对IO网络的堵塞,那么这样的后台服务又有什么用呢?
      EMPLOY任务线程指派算法,要看具体业务来定,如果所有业务实现数据传输量大小差不多,反应时间长短都差不多的话,可以采取平均顺序分配的方式,否则可以按照业务具体调用来指派某一个或多个EMPLOY任务线程来处理。
      如果再做的好一点的话,应该对每个EMPLOY任务线程进行监视,如按照已有任务队列长度来决定分配哪个线程。
2、性能保证;
      必须保证正常通信过程中,各个连接、各个线程之间基本没有共享数据锁机制,否则性能肯定大打折扣;
      对于Buffer访问机制,应该采取类似Linux内核技术的循环缓冲机制,其最大特点就是如果同时只有一个写线程和读线程时,此循环缓冲不用加任何互斥锁机制,这样性能才会保证;
      对于socket本身进行的一些参数优化,如:设置SO_SNDBUF为零,可以减少用户态到内核态的复制CPU耗时。
3、错误处理;
      IOCP最大的难点之一,就是在连接断开情况下的资源回收,推荐两种办法:
      3.1、采取延时回收策略,在保证所有Buffer对象都在一定时间内回到队列后,再释放该连接的所有资源,前提是要看你的业务接口运行速度了,一般30秒左右应该足够了吧?!
      3.2、采取即时回收策略,但是必须对多线程情况下考虑加入Buffer计数器,当所有Buffer被回收到当前连接对象后,并且EMPLOY任务线程中悬而未决的该连接任务个数为0时,马上进行回收处理。
4、容错机制;
      主要是对包本身是否非法的检测,一般采取:4字节包头长度位+N字节数据位的协议模式,这样服务端只需每次解读包头来判断是否合法,
      客户端API必须保证封包的正确性,一定要避免分片报文以杂序排列发到服务端;
      如果服务端收到某连接有非法数据报文,应该主动关闭连接。
5、业务接入。
      业务继承开发接口一般只需要关注三个方法:连接、断开连接、读取数据;
      业务接口只需要继承并重载父类的读取数据方法,并在构造完回复数据后,调用父类的发送方法;
      应该保证业务接口实现的高效性,避免一条鱼腥了一锅汤的情况发生。

二、关于测试
性能测试建议样例:
1、每客户端平均0.5秒发个请求,报文大小100字节左右;
2、服务端回复1024字节;
3、连接个数10000;
4、服务器是R710,8核;
5、网络是千兆。

测试回应均值应不多于500微妙,好的可能达到100微妙以下,否则你的设计肯定有问题。

三、互斥锁的使用
你的服务端设计一般只有两个锁机制:
1、每个连接对象的自锁,用来保持连接对象中一些变量的同步;
2、所有连接的集合,一般为MAP,用来insert、remove客户端连接时使用。

除此以外,你不应该再增加其他锁。

展开阅读全文

没有更多推荐了,返回首页