楼楼做这个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的知识了.
