问题描述
楼楼做这个mina的服务端的时间大概不到一个月. 楼楼之前主要是做http的编码,对socket的了解也不是很深, 但因为mina的易用性所以整个服务端也算是很快就搭建起来了. 在和客户端对接测试的时候稳定性和服务端的功能也都还算满意.所以兴冲冲的就开始做压力测试了. 压力测试一做就做出来一身冷汗. 楼楼的服务器是4核的,所以服务端启动的ioprocesser=5. 目前最大的问题是: 当session数量到达100以上时. 客户端收到服务端响应的时间大约就要2到3秒, 当同时并发2W时 响应时间居然达到了惊人的2000多秒.而且此时数据库IO操作居然并不繁忙.一个session会每隔几秒有一个操作.每个操作至少会有1次数据库的读写. 在网上也查了很多地方,好像没有人出现过我这种响应时间很长的情况.不知道是不是我哪里配置的不对. 楼楼是临时花了一上午用mina编写压力测试客户端, 使用多线程启动connecter 来建立新session. 1秒建立10个session.(session的建立很顺利,服务端也能很快将session建立起来,就是数据的读写响应时间非常长) 最开始因为有多次的ACK操作在高并发的情况下客户端老是出问题.抛出了无数的异常,然后反过来又引发服务端无数的异常.于是先去除了服务端的ACK操作. 大大的减少了异常的产生. 再然后觉得需要加上响应时间.所以就在 客户端的请求上 附加了时间戳. 服务端返回时将时间戳直接返回来 在比较当前时间戳与发送请求时的时间. 当时就发现这个响应时间在高并发下是一个非常恐怖的数字. 因为在高并发时数据库的读写非常轻松 , 感觉并不是逻辑处理的问题导致响应时间长, 干脆先将所有的功能性的逻辑去除. 将服务端的流程缩短到接收->解码->发送->编码. 但是对缩短响应时间几乎没有影响.. 目前下一步的打算是在session建立时保存时间戳. session有操作时比较时间戳. 看看时间到底是浪费在什么地方. 希望有高手能指点一下出现这种响应时间长的情况是什么问题. 实在没有找到别人也有碰到mina响应时间过长的情况. 看来还是要多补补socket的知识了. 问题补充：我在服务端各个节点加上了时间戳. 目前还没有在客户端加. 下一步在客户端也加上作比较.客户端是在session一创建.就马上把数据发过来了.session创建->开始decode 111846ms开始decode->完成decode 0ms调用messageReceived 63msrecv后马上返回数据开始encode 0ms开始encode->完成encode 0ms完成encode->调用messageSent 13885ms.等下再把客户端的时间轴也发出来...其实整体来看时间主要就是消耗在收到信息这里
解决方案
mina是nio框架。nio框架是用的select 模型，通过在少量线程中 轮换处理当前有数据事件的链接来节省数据资源。因此每次接收到数据后的处理时间不能长，否则会整体性能会很快下降。看上面的时间统计，貌似你的decode处理有问题，不会是直接用read到一个数据包完整接收到的吧？mina应该提供定长数据包的decoder和delim分隔的数据包的decoder的。
解决方案二：
性能瓶颈应该不在processer的数量，processor从channel中读取数据还是很快的，我觉得应该是在读取数据后的过滤链中fireMessageReceived的调用过程这，所以只需要增加线程池过滤器即可，考虑到decode与encode比较耗费时间的情况，可以设置线程池过滤器在编解码过滤器之前。