Webgame的mina聊天服的优化

 使用Mina做了一个WebGame的聊天服,已上线几个月了,鸭梨相当的小,以此文记录经验一二。

    与前端flash使用协议AMF3。

     一、压力测试与修改(cpu*2+memory*4)

      1、内存增长迅速,cpu占用偏高

      原因:广播的同一条消息都进行了AMF3-Object->buffer的编码

      改进:一次编码,通过buffer进行复制

      2、Too many open files

      原因:打开文件描述符号太多,超过系统默认限制,默认open files (-n) 1024

      修改系统设置ulimit -n 65535

      3、小机器人client最多开到440左右

      原因:windows默认端口1024-5000,小机器人使用mina写的,clientTcpPortNum=(NIOAcceptor.Selector*1+NIOProcessor.Selector*1(CPU*2+1))*2+clientPort=9

      修改系统设置regedit->[HKEY_LOCAL_MACHINE /System /CurrentControlSet /Services /Tcpip /Parameters] ->MaxUserPort=65534

      4、系统瓶颈:(全广播)200client*(250message*1second)=50000或者2000client*(25message*1second)

      原因:网卡write到瓶颈(100M网卡4-8M/s),消息在write后积累,内存迅速吃尽,cpu满负荷。(1条消息(200k)=HeapByteBuffer*1+DefaultWriteFuture*1+DefaultWriteRequest*1+EncodeWriteRequest*1+MessageWriteRequest*1=5)

      修改:引入消息队列控制发送模式

 

    二、消息立即发送模式与队列控制发送模式自由切换

    任何系统都有瓶颈,尤其是硬件条件有限的情况下。如何在有限的硬件条件下既保证系统的吞吐量及一定的响应能力,又保证系统的健壮性和稳定性,不至于系统因为瓶颈(系统负载运行高峰期)而崩溃,的确让人深思。

    最后我决定使用优先级队列控制消息的发送时间及频率,在极端情况下,丢弃优先级较低的消息。

    1、使用开关变量控制两种发送模式,默认情况下使用立即发送模式;

    2、开启一定时线程监测系统运行状况,包括积累消息数、内存使用情况、cpu(由于cpu监测耗时比较大,后来去掉了)、队列中消息数等;

    3、根据系统运行状况以及硬件情况(cpu+memory+nic)进行两种模式的自由切换;

    4、消息队列根据消息业务逻辑,如用户聊天信息、小公告信息、系统公告等进行优先级划分。

你可能感兴趣的:(Mina)