三、Network
Network 资源监控的KEY包含:

KEY 说明
net.if.collisions[if] 网络冲突数量。返回整型
net.if.in[if,] 网络接口上传流量统计。返回整数
net.if.out[if,] 网络接口下载流量统计。返回整数
net.if.total[if,] 网络接口上传下载流量统计。返回整数

Read More

二、Memory(含Swap)
Memory 资源监控的KEY包含:

KEY 说明
vm.memory.size[] 内存大小
system.swap.size[,] 交换分区空间大小
system.swap.in[,] 交换分区(从设备到内存)统计数据,返回整数
system.swap.out[,] 交换分区(从内存到设备)的统计数据,返回整数

Read More

操作系统的监控是性能监控的基础,Linux是目前的主流的服务器端操作系统。下面先从Zabbix对Linux 的监控入手。

Zabbix对Linux的监控项,从性能测试的角度看可分为 CPU、Memory(含Swap)、Network、Filesystems、Processes 几大类。

一、CPU
CPU资源监控的KEY包含:

KEY 说明
system.cpu.intr 设备的中断数。返回整数
system.cpu.load[,] CPU 负载。返回浮点数
system.cpu.num[] CPU 数量,返回整数
system.cpu.switches 上下文的数量进行切换。返回整数
system.cpu.util[,,] CPU 使用率。返回浮点数

Read More

Zabbix 是一款常见的运维监控工具,可以方便的监控多种主机系统资源,JVM资源 以及其他各种可用脚本抓取的资源。
目前我们尝试使用Zabbix 作为性能测试的一般性监控工具,主要原因有三点:
1、性能测试环境的主机有100多台,单机形的工具面对这么多机器显得很无力,因基础监控不全而导致各种无效分析时有发生。每台机器都安装Zabbix后,基础监控数据一目了然,可快速发现问题。
2、zabbix 可通过命令行方式获取监控数据,便于扩展。
3、zabbix 数据落地到数据库中,便于后期分析,便于自行捞取数据,生成报表。

工欲善其事,必先利其器,既然使用Zabbix做为性能测试的监控工具,我们就先的搞清楚Zabbix可以提供哪些监控。
下面将分为Linux 、JVM、Redis、Mysql分别研究。

Jmeter的整体代码结构可参考官网wiki( http://wiki.apache.org/jmeter/DeveloperManual/DirStructure )。

总体代码量不是算小,如何阅读是一个问题,反复思量,决定从一个最简单的例子入手。

一个性能测试的实例至至少应包含多线程执行一项测试任务和收集汇总测试结果这两部分。首先抛开对多线程和测试结果的注意力,我们先构建一个最简的测试任务。

jmeter除了支持HTTP、FTP之类的应用协议外,还可以自己编写java代码作为测试项,这样,我们可以抛开各种繁文缛节的协议,看到最简单的东西。

import org.apache.jmeter.config.Arguments;
import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
import org.apache.jmeter.samplers.SampleResult;

public class DemoJavaTest extends AbstractJavaSamplerClient {
    @Override
    public SampleResult runTest(JavaSamplerContext context) {
        SampleResult sr = new SampleResult();
        sr.sampleStart();
        try {            
            // 做想做的事情
            sr.setSuccessful(true);
        } catch (Exception e) {
            sr.setSuccessful(false);
        }
        sr.sampleEnd();
        return sr;
    }
}

Jmeter是一款应用较为广泛的开源性能测试工具,由于工作中接手了前辈遗留下来的Jmeter插件,因此需要搭建一个Jmeter的调试环境。

Jmeter官网提供了一个SVN地址的获取页面( http://jmeter.apache.org/svnindex.html ),通过指引,我们可以从 http://svn.apache.org/repos/asf/jmeter/trunk 获取一个只读的版本。

下载后,需要将 eclipse.project、eclipse.classpath 两个文件改名为.project、.classpath,这个地方比较坑,Win7上直接改名被拒绝,只能打开CMD窗口用rename命令解决。搞定后可以在eclipse导入这个工程,

Read More

最近做性能测试遇到一个恼人的CLOSE_WAIT问题,压测JAVA应用,服务器上出现大量的CLOSE_WAIT,最后造成应用无响应。

从《TCP-IP详解卷一:协议》第18章的图18-12 TCP的状态变迁图可以看到,当收到FIN返回ACK后,状态变为CLOSE_WAIT,如果程序发FIN则状态继续变化,否则就僵死在这里。也就是说,服务端程序一直没有发送FIN。

TCP的状态变迁图

从tcpdump抓取的数据可以看到,客户端与服务端之间5分钟没有交互,则客户端(65.56)发送FIN给服务端(65.139),服务端返回ACK后再无下一步的动作,因此一直是CLOSE_WAIT状态,符合前面的表述。

tcpdump抓取的数据

Read More

Spring框架的重连机制研究

Spring提供了2个MDP容器:org.springframework.jms.listener.DefaultMessageListenerContainer、org.springframework.jms.listener.SimpleMessageListenerContainer。

DefaultMessageListenerContainer重连机制

DefaultMessageListenerContainer启动内部类AsyncMessageListenerInvoker作为线程。

DefaultMessageListenerContainer重连机制

Read More

测试方法的研究

如前文所述,我们需要测试测试心跳故障和连接故障下的TIBCO表现。

经过测试可以发现:

1、 无论在主服务器的TIBCO控制台输入shutdown,还是在Linux命令行下使用kill -9杀TIBCO进程,主服务器均向客户端发送了FIN,ACK,友好的关闭连接,同时也向备份服务器发送了FIN,ACK,备份服务器和客户端均可判断出连接故障,备份服务器开始做主备切换,客户端向备份服务器发送SYN,创建新的连接。

图1 客户端向备份服务器发送SYN,创建新的连接

这两种操作方式均满足连接故障的要求。

2、 直接重启主务器,TIBCO日志显示:

Missing heartbeats from primary server ‘tcp://192.168.65.121:7222’.
Server activating on failure of ‘tcp://192.168.65.121:7222’.
Server rereading configuration.
Recovering state, please wait.
ERROR: Unable to open store file ‘/mqdata/QA/QAEmsServer1/datastore/async-msgs.db’, file may be locked.
ERROR: Unable to open store file ‘/mqdata/QA/QAEmsServer1/datastore/meta.db’, file may be locked.
ERROR: Unable to open store file ‘/mqdata/QA/QAEmsServer1/datastore/sync-msgs.db’, file may be locked.
ERROR: Server failed to recover state.
Server is re-entering standby mode.
Missing heartbeats from primary server

可以清楚的发现,备份服务器检测到心跳异常,并作恢复尝试。

客户端连接的TCP消息,可以看出主服务器未发送FIN,ACK来优雅的关闭连接,客户端数次重传失败后,转而连接备份服务器。

图2 客户端数次重传失败后,转而连接备份服务器

但是需要注意的是:主服务器重启完毕并挂载nfs前,datastore一直处于被锁状态,无法完成主备切换,生产或类生产环境是否存在同样的问题,值得关注。

重启服务器可以满足心跳故障的测试需求。

Read More

我司使用TIBCO做为JMS中间件,最近需要做应用的JMS相关容错测试,因此对TIBCO的容错性做了粗浅的研究。

TIBCO提供了主备模式的容错设计,通过配置一对服务器(一主一备)进行容错。正常情况下,主服务器接受客户端的连接和传递消息,一旦主服务器出现故障,备份服务器变为主服务器继续工作,原来的主服务器恢复后,变为备份服务器。

架构上可分为:共享状态模式、非共享状态模式。非共享状态模式在故障切换的时候会出现消息丢失、重复等问题。我司目前使用的是共享状态模式。

图1共享状态

图2 非共享状态

共享状态

为了提供最大程度的故障切换保护,主服务和备份服务必须共享相同的状体,这些状态包括三个方面:
1、 持久化的消息数据
2、 主服务的客户端连接
3、 消息传递的元数据
当发生切换时,备份服务器重读所有共享信息。

Read More