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、消息队列根据消息业务逻辑，如用户聊天信息、小公告信息、系统公告等进行优先级划分。

 

     就到这里了，该吃中饭了。