分享
 
 
 

完成端口之性能优化(2)

王朝other·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

本文作者:sodme本文出处:http://blog.csdn.net/sodme

版权声明:本文可以不经作者同意任意转载,但转载时烦请保留文章开始前两行的版权、作者及出处信息。

前面有朋友对本系列文章的题目提出质疑,说:这恐怕不能算是性能优化吧?我要指出的是,本系列文章中提到的优化并不仅仅是某段具体的代码优化,当然这种东西肯定会有,但优化绝不仅仅是这些方面,我这里提到的优化还包括更多的关于模型架构方面的考量。

上次我提到,在模型里,引入“池”的概念可以有效改善服务器效率。对于完成端口来说,它处理的是成千上万个的客户端连接。在单一客户端连接的情况下,偶尔的多余操作可能并没有给你的系统带来什么不良影响,但这在形如使用完成端口构建的高性能服务器上是绝对应该避免的,不然,你会发现用了完成端口说不定还没有用其它模型来得高效。另外,需要指出的是,完成端口并不是万能模型,有的地方可以考虑用,而有的地方则完全没必要用,至于完成端口在网游服务器模型里的具体使用,我会在另外的文章里提及。

“池”的概念的引入,最主要的是想让服务器在运行时,维护一个相对静态的数据存储空间,并在这个相对静态的空间上进行相关操作。但是,尽管我们千方百计在诸如此类的地方引入“池”,还是不可避免地要遇到这样的几个问题:拼包操作时的数据移动,内存数据的拷贝,socket与客户端对象的一一对应和定位等。下面,将会针对这三方面介绍有关的优化细节。

为讨论的方便,在此引入几个状态常量:

stAccept:表示处于连接建立状态;

stRecv:表示处于数据接收状态;

stSend:表示处于数据发送状态。

注:本文及后续文章,会简称“GetQueuedCompletionStatus”函数为“Get”函数。

现在我们要讨论的是当Get函数返回时,处于stRecv状态时的数据包拼装问题。我们知道,TCP是流协议,它的数据包大小并不一定就是我们期望的发送或接收时的逻辑包大小,每次发送或接收的大小到底是多少,是根据网络的实际状况来决定的。一个在逻辑意义上完整的包,可能会被TCP分为两次进行发送,第一次发送前半部,第二次发送后半部,由此便带来了不完整数据包的拼装问题。那么,要实现数据包的拼装,必须要有一个地方,可以把两个半截的包放到一起,然后从首部根据逻辑包里的大小定义字段取出相应长度的逻辑包。“把两个半截的包放到一起”,这个操作,就涉及到了数据拷贝问题。在实际的应用中,有两种拼装方案可供选择:第一种方案,是将新收到的后半部分数据包复制到前半部分数据包的末尾,形成一个连续的数据包空间,在此空间的基础上进行拼装操作;第二种方案,不用把新收到的后半部分数据包复制到前半部分的末尾,而是在现有两个缓冲区的基础上直接进行拼装操作,当从前半部分搜索到截开的位置时,将指针直接指向新包首部,取走一个完整逻辑意义的包。

不论是哪种形式的拼装,都会或早或晚地牵涉到剩余数据的拷贝转移问题。第一种方案的情况下,会执行memcpy将新收到的数据包,复制到前半部分数据包的后面;第二种情况,尽管不会首先执行memcpy执行复制,但当执行了“取走所有完整逻辑包”的操作后,缓冲区里可能会残留一个新的不完整的数据包,此时仍需要执行memcpy操作将剩余的这个不完整的数据包复制到原来的前半部分数据包所在的缓冲区,以跟其后续的不完整数据包完成下一步的拼装操作。两种方案的效率,比较起来,第二种方案执行memcpy时所复制的数据内容可能要小得多,所以,相对来说,第二种方案的效率要高一点。

memcpy函数的优化,在google上可以搜索到相关主题,用的比较多的优化函数是fastmemcpy,本处给出有关memcpy函数优化的两个连接地址:

http://www.blogcn.com/user8/flier_lu/blog/1577430.html

http://www.blogcn.com/user8/flier_lu/blog/1577440.html

请有兴趣的朋友认真阅读一下这两篇文章。优化的核心思想是:根据系统硬件体系架构,来确定最优的数据拷贝方案。根据以上给出的两个连接地址,memcpy会得到较为明显的优化效果。

对于网络层来说,每个连接到服务器的客户端唯一标识就是它的socket值,但是,很多情况下,我们需要一个所谓的客户端对象与这个socket能够一一对应,即:以socket值来确定唯一的客户端对象与它对应。于是,我们很自然地会想到使用STL里的map完成这种映射,在实际的使用时,会通过map的查找功能根据socket值取出相应的客户端对象。这样的作法,是较为普遍的作法。但是,尽管map对它的查找算法进行了相应的优化,这个查找也还是要花费一定时间的。如果我们仅仅是要在IOCP的模型里通过GET函数返回时,确定当前返回的socket所代表的那个客户端对象,我们完全可以对投递的overlapped扩展结构进行相应的设置来通过GET函数返回的overlapped扩展结构来直接定位这个客户端对象。

我的overlapped结构是这样的:

struct Per_IO_Data {

OVERLAPPED ov;

.....

CIOCPClient* iocpClient;

.....

}

大家可以看到,在我的扩展overlapped结构中,我引入了一个客户端对象指针:iocpClient,每次在投递一个WSASend或WSARecv请求时,都会顺带着这个客户端对象指针。这样,当WSASend或WSARecv操作完成时,就可以通过GET函数执行后返回的Per_IO_Data结构取得这个客户端对象指针,从而就省去了根据socket值进行map查找的步骤。在持续的数据收发下,如果在GET函数里频繁地进行map查找,势必会对性能有较大的影响,而通过传递客户端指针到扩展overlapped结构中实现客户端对象的直接定位则大大节省了查找的时间开销,无疑在性能优化方面又作出了一个重大改进。

<未完待续>

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有