MINA使用心得及相关要点，有一个bug的解决方案，不知道其它朋友是否遇到过（一）

这位仁兄的深究精神值得我去学习，我还真没有使用原生的nio去做这个bug的测试，一直以为是mina的原因。但对你上面这句话我得再次重复一次，并不是要争论什么。任何事物，存在即是道理。所以sendUrgentData还是有其市场的。
适用环境如下：
1、对sendUrgentData方法支持
2、客户端和服务端都可控（这个条件其实是次要的，不一定是必需的。）

我程序里面只所以使用sock.setOOBInline(true);是因为在nio中有BUG存在，所以不得不打开这个选项并另外写程序处理紧急字符。但正常情况下，OOBInline默认是FALSE的。所以不用你特意去写程序处理，服务端接收到该紧急字符会自动抛弃的，所以个人认为在以上二种情况下，测试 “连接保活”直接就用sendUrgentData方法就可以了

你之所以问出的这二个问题，大概是对mina的运行机制还没有吃透，影响其性能的，并不是selector,而 ioprocess，理论上来说，CPU的核心越多，你的IOPROCESS可以开得越多，这个在生成 IoAcceptor 可以自己设置。
如下：
IoAcceptor acceptor = new NioSocketAcceptor(10);

用的单机。实际上如果测试环境能提供三台机器，并将前置机的三个部分分开放的话，其性能应该更加高效。最高的并发数没有测试过，但据说有人上过6.5W.  
但这个性能这东西，影响的因素太多了，所以单纯问单机并发量多少没有实际意义，主要还是跟你的内部业务逻辑有关，简单的话，并发量就高，复杂的话，并发量就低，总之够用就行。如果上了mina还感觉性能提升不大的话，建议二点。
1、优化代码
2、在设计上动脑筋，将业务分开处理，进行均衡。比如说在我的项目中，就是将业务分成了三大部分来处理。这样开发起来快，在性能上面也非常有优势。

我对MINA仅限于一些学习和研究，实际工作中并不打算用MINA。所以我更多的对只跟JavaNIO相关的内容感兴趣。我想知道的是你们实际运行环境中的数据，并不是怎么用MINA设置参数。具体的比如同时管理多少Socket连接，每秒处理多少次请求，请求及其应答的平均数据量有多大、使用了多少个Selector等。如果你方便透露的话。

希望有人能讨论下这个：http://www.iteye.com/topic/1111992

生产环境中同时管理的socket有2W,登录时是2W同时并发的，从接收终端数据到数据入库，大概要90秒左右，
处理速度： 2W*2/90=440次左右（之所以*2是因为登录之后会马上发送一个心跳帧，心跳周期为30秒，按这个来算其实应该*3，但考虑到一些其它因素，这里按2来算，就绝对不会存在虚高部分了）。
登录和心跳的  每次请求的字符数在51个左右。

应答是在有心跳帧、登录帧及退出时时才有确认帧，所以应答的数据量和处理速度与上类同。基本上与登录部分是并发的，从这个角度来说，总体处理速度应该是  440*2.   

至于selector这个是mina内部控制的，由于有些概念还没有摸得十分清楚，从个人理解上来讲，好像是二个，一个用来轮询是否有连接产生，一个用来轮询IOProcess. 
数据部分不知道对你是否有帮助，后面的理解部分，还请高人指正。

谢谢你解答得这么详细！
90秒是否也是每个连接上的终端数据采集发送的平均周期或更长？
从你的描述看来系统压力在数据库上，每秒四百多次的处理速度以及不到100个字节的请求数据和更少量的应答数据应该对网络框架不构成压力，管理更多的连接也应该没有问题。

90秒是2W终端并发登录，到数据库记录下全部终端在线状态的时间。

是的，我说过了，私底下我们的测试已经上到3.5W了。因为机器不够用（每台机只能开6K-15K的端口），而客户要求只需要2W的并发，所以就没有必要自讨苦吃了。但从测试的反应来看应该能上更高。个人估计5W木压力。。。

sendUrgentData保活，不能理解，java接收端无法区分带内数据和常规数据，urgent数据也仅是理论上来说能够绕过常规数据流先接收，这样的话好像与常规发送一个-16没什么区别？
MINA的selector默认情况下有CPU core+2个，其中一个是专门用于接受连接，剩下CPU core+1个，绑在了CPU core+1个IoProcess里，每个IoProcess一个selector，用于具体IO，设计很巧妙

没有没有没有没有