测试环境
服务器
硬件配置: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(实际本次测试用不到)