openfire 3.7 压力测试一（注册）

测试环境

服务器

硬件配置：CPU E5620  @ 2.40GHz X2（16核），内存 32G
操作系统：CentOS release 5.4（64bit，内核2.6.18）
机器上安装有一vm，vm运行openfire数据库，对性能会有一定影响。
openfire 运行参数：openfire -Xms16g -Xmx16g -Xmn8g -XX:MaxPermSize=512m -XX:PermSize=512m

测试机配置
PC机 2.2G双核,1.5G可用内存

测试环境

测试机与服务器间为100M网络，测试机6个线程（受测试机条件影响，但已能较大程度模拟并发）同时不间断共创建60万用户。

测试目的

模拟大并发同时注册为openfire用户，监控服务器瓶颈。

服务器监控

测试开始前，服务器使用IBM基于GPL的unix/linux资源监控软件nmon。

[root @testserver128 nmon_data]#nmon -s1 -c600 -f -m /opt/evas/data/nmon_data/

即每秒采集一次硬件资源，共采集600次，即10分钟，日志保存到指定目录。10分钟后（实际用户未创建完成，大概创建50多万，未出现错误），目录下生成带机器名及时间标称的记录文件：

[root@testserver128 nmon_data]# ls
testserver128_110614_1544.nmon  testserver128_110614_1645.nmon

[root @testserver128 nmon_data]# ls
testserver128_110614_1645.nmon

将文件下载到本地windows环境，在接下来的分析过程中将使用到这些原始数据。

数据分析

数据分析依然使用IBM免费的配套分析软件nmon_analyser，说是软件，但它只包含一个excel文档（另含readme)，不得不佩服蓝色巨人的强壮，使用几个vb代码在excel中就能完成如此强大的功能。

使用excel打开解压后的nmon analyser v33g.xls，可能需要将excel安全级别降低才能正确运行宏。打开后，点击其中的按钮，选中刚才下载的lstestserver128_110614_1645.nmon，即生成另一xls，接下来便可查看到性能监控结果。

测试数据：10分钟时间完成53万个注册，平均每秒883个成功注册，考虑到单机(PC机)测试，测试机的性能影响到测试结果。

从图示可以看到，整个测试过程，CPU的压力无明显变化，用户注册请求对openfire压力非常小，仅占到1%-2%，最大约6%，但持续时间非常短。 
上图为整个测试过程CPU使用情况，也能很明显看到用户占用较小，有点奇怪压力居然集中在一个核上。 
上图为测试过程磁盘读写IO情况，因为服务器上装有虚拟机以运行数据库，测过过程可能会存在一些影响。整体来看，与平时未进行压力测试波动不大。且测试过程nmon需要写日志，openfire也需要写日志，会影响测试结果。 
磁盘写偶尔有波动，大部分时间是正常波动。 
测试过程内存也无明显波动，主要原因是openfire运行在jvm中，该监控工具无法监控到jvm内存变化情况。

openfire服务器已连续运行6天多，测试后的gc日志：

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

  0.00  59.39  99.56   8.36   6.38     23   14.514     1    0.768   15.282

运行6天（含测试后）仅发生过23次YOUNG GC，1次FULL GC。但也能看到，YOUNG GC开销的时间较大，这与新生代配置较大有非常大的关系，需要对JVM参数进行优化以压缩GC时间。

JVM永久区内存存在大量浪费，老年代也存在大量浪费。内存多了，用起来也就大手大脚，导致以上小问题。

网络压力也在完全可接受的范围，甚至可以无视。 
整个测试过程，最辛苦的一个cpu(核)的使用情况。

测试过程服务器资源概况： 
比较明显看出CPU比较正常，IO会有些跳跃，但总体也不是瓶颈。通过整个测试过程来看，高并发的用户注册请求对openfire系统压力影响不大。

测试过程出现的问题

1、操作系统最大打开文件数的问题，默认才1024，修改为100000（实际本次测试用不到）