Openfire服务器简要评测

最近在预研Openfire，也简单的对其进行了一下评测。评测的方法有很多种，我试了自己用代码测试和用专业测试工具两种方案。
首先是自己写代码测试，这时候的测试是基于windows 7 openfire 3.9.1，1G JVM，2G内存，Intel G3320 2.9 CPU，配置较低，公司给配的个人开发机也就这样。
（1）写JAVA代码，带用SMACK接口，注册了20W用户;
        （2）为了测试这样的配置下，到底可以运行多少客户端，用JAVA多线程的方式，每个线程模拟一个客户端，同时有读和写的功能。为了得到最真实的数据，没有改动JVM的大小和每个线程的堆栈空间，因为我们写JAVA程序的时候基本不会主动调整每个线程的堆栈空间。最后运行测试代码，最大并行登录用户数为300个左右，同时并行往一个客户端发消息，到客户端解释完成，消息响应总时间为46毫秒，即平均消息响应时间为0.15毫秒左右。
（3）为了测试更大的登录量，为了效率，改用C++代码编写客户端，调用gloox开源库。
首先为更大的容量，将线程大小设置为1M(在后来测试中，发觉这个值根本不能再小了，就算你调整到1K，可是最小的线程堆栈空间以系统分页大小为准，所以有最小值1M左右)，依然一个线程模拟一个用户登录，在登录到1360用户的情况下，出现卡CPU的情况，后面出现了客户端模拟程序内存崩溃。
然后为了更大容量的登录，采用一个线程里面起多用户的策略。在一个线程内模拟256个客户端，客户端单独部署在一内存4G电脑下，单机总共登录了大概28000的用户，之后出现掉线情况。在这样的情况下，已经击破了网络上所流传的单机Openfire只能支持5000用户的谣传。
在可用资源下，又加了一台4G 32位Win7的个人PC，即客户端模拟PC达到两台，然后分别运行模拟客户端，轻轻松松突破5W用户，看Openfire的1GJVM内存，才用到600M（处理登录认证的时候CPU和JVM占用大一些，登录成功后保持连接就占的很少了）。所以依我估算，裸机的Openfire（不用连接管理插件），支持20W+用户登录都是可能的。这个猜测后续有空在测，5W已经满足我现在的需求了。
测完登录容量，该看看并发了，前面自己写的代码只是大致对并发摸了一下底，如果真想达到并发，这样配置用自己的代码简直就是坑自己啊。
  所以这里测并发，我采用了linux系统，虽然服务器配置很差，也就4G内存，Intel G3320 2.9的CPU ，然后装了一个Centos的32位系统。
就这样的配置你们猜支持多少并发？
这里采用TSung测试工具，首先得装erlang，然后才是Tsung。Openfire的JVM稍微改大了一点，到了1.5G。数据库依然采用Mysql; 然后调整了系统的最大进程数和打开分页大小。
  （1）首先看注册，用了Tsung的脚本，目标20W，最后成功的也就5万多一点。为了测试更细化，分批次运行测试脚本，前两次目标4W，注册成功了两万多点，后面的无论设置目标多大，我设置了目标十万，最后都是成功一千左右，完全比不上自己写的代码啊。
（2）注册不说了，再来看登录。为了省事，客户端和服务器就用一台电脑。这样的配置下，我最大的登录用户数为20800个，后面怎么调整系统和脚本就这么大了。或许将客户端单独用一台电脑搞会大些，以后有空完善。
  （3）好了，看最关心的并发。调整登录的脚本，在登录完成后，等待五分钟，等所有用户全部登录成功。然后开始并行往服务器请求好友列表，用这个操作做并发的好处，就是刚好一次请求，一次返回，简单明了，没有干扰。
一万用户并发，大概平均消息相应时间在0.6毫秒左右，服务器平均消息处理时间在0.4毫秒左右;
两万用户并发，大概平均消息相应时间在2毫秒左右，服务器平均消息处理时间在1.5毫秒左右;
这样的低配，却得出这样的高性能参数，不得不说Openfire在通信上真的已经做的很好了。
以上的评测都是自己的简单评测，更精准的需要更多时间和经历，如果以后有需要再补上。