ououming123
ououming123
2014-03-11 15:45
浏览 477
已采纳

mina高并发下响应时间过长的一些失败的尝试及寻求正确方法

楼楼做这个mina的服务端的时间大概不到一个月. 楼楼之前主要是做http的编码,对socket的了解也不是很深, 但因为mina的易用性所以整个服务端也算是很快就搭建起来了. 在和客户端对接测试的时候稳定性和服务端的功能也都还算满意.所以兴冲冲的就开始做压力测试了. 压力测试一做就做出来一身冷汗.
楼楼的服务器是4核的,所以服务端启动的ioprocesser=5.
[color=orange]目前最大的问题是: 当session数量到达100以上时. 客户端收到服务端响应的时间大约就要2到3秒, 当同时并发2W时 响应时间居然达到了惊人的2000多秒.[/color]
而且此时数据库IO操作居然并不繁忙.[color=blue]一个session会每隔几秒有一个操作.每个操作至少会有1次数据库的读写.[/color] 在网上也查了很多地方,好像没有人出现过我这种响应时间很长的情况.不知道是不是我哪里配置的不对.

楼楼是临时花了一上午用mina编写压力测试客户端, 使用多线程启动connecter 来建立新session. 1秒建立10个session.color=red[/color]

最开始因为有多次的ACK操作在高并发的情况下客户端老是出问题.抛出了无数的异常,然后反过来又引发服务端无数的异常.于是先去除了服务端的ACK操作. 大大的减少了异常的产生.

再然后觉得需要加上响应时间.所以就在 客户端的请求上 附加了时间戳. 服务端返回时将时间戳直接返回来 在比较当前时间戳与发送请求时的时间. 当时就发现这个响应时间在高并发下是一个非常恐怖的数字.

因为在高并发时数据库的读写非常轻松 , 感觉并不是逻辑处理的问题导致响应时间长, 干脆先将所有的功能性的逻辑去除. [color=orange]将服务端的流程缩短到
接收->解码->发送->编码. 但是对缩短响应时间几乎没有影响..[/color]

目前下一步的打算是在session建立时保存时间戳. session有操作时比较时间戳. 看看时间到底是浪费在什么地方.

希望有高手能指点一下出现这种响应时间长的情况是什么问题. 实在没有找到别人也有碰到mina响应时间过长的情况. 看来还是要多补补socket的知识了.

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • iteye_7589
    iteye_7589 2014-03-13 09:48
    已采纳

    mina是nio框架。
    nio框架是用的select 模型,通过在少量线程中 轮换处理当前有数据事件的链接
    来节省数据资源。

    因此每次接收到数据后的处理时间不能长,否则会整体性能会很快下降。

    看上面的时间统计,貌似你的decode处理有问题,
    不会是直接用read到一个数据包完整接收到的吧?

    mina应该提供定长数据包的decoder和delim分隔的数据包的decoder的。

    点赞 评论
  • gg22aa
    gg22aa 2015-06-04 17:26

    性能瓶颈应该不在processer的数量,processor从channel中读取数据还是很快的,我觉得应该是在读取数据后的过滤链中fireMessageReceived的调用过程这,所以只需要增加线程池过滤器即可,考虑到decode与encode比较耗费时间的情况,可以设置线程池过滤器在编解码过滤器之前。

    点赞 评论
  • wl1297929289
    wl1297929289 2017-05-03 08:49

    楼主,我这里现在也遇到这样的问题,你的问题解决了吗,是自己做到的?现在服务端没有数据的逻辑处理代码,响应的时间还是很慢。

    点赞 评论