一次性能测试的总结

有机会做了一次性能测试工作，主要是预研性质的工作。开发人员有必要再提交给测试做性能测试之前，做一次比较粗糙的性能测试工作。
1）走通性能测试流程，从造数据到测试，可以走通，方可交由测试同学。毕竟开发（相对性能测试人员而非功能测试）对业务逻辑更了解一些。
2）测试一些显而易见的bug；
3）建立性能方面的信心；
4）可在测试的同学做完测试以后做一个对比，不至于偏离太过离谱。

参照测试部门的意见，我把这次的性能测试总结了如下几个步骤：
1、测试目标和范围：根据需要满足的非功能需求，确定上线功能点哪些需要测试。测试性能、稳定性、最大压力。
2、测试方案准备：包括施压方式，环境配置，环境依赖，资源监控，整理方案文档。
3、环境准备：准备压力测试环境，一般是压力测试机配置，压力测试数据库配置。
4、数据准备：根据线上预估数据，对数据库数据进行准备和模拟。
5、测试准备：包括需要编写的程序，如其他系统间依赖可写mock程序。另外编写jmeter的测试计划等。尝试测试，并确保一个请求或处理过程能顺利通过。
6、进行测试：通过客户端施压服务器，监控器各方面资源利用。
7、进行测试分析总结，写测试报告。TPS，吞吐量，CPU占比等。对异常现象记录，如内存溢出等。
8、根据测试报告对程序进行优化或重构。


做技术还是有做技术的天性，我们开发最关心的也就是5-8的步骤。我们的应用主要以hessian接口的形式向外面暴露，另外的就是任务在后台处理接口推送过来的数据。所以，我们的测试主要集中在接口测试和任务测试。比一般网页的性能测试更简单一些。

我们选用的施压客户端是开源的jmeter，文档较为丰富，且操作极为方便，扩展性好。服务器端性能监控工具，均采用linux的shell命令和jvm自带的工具或命令。jvm的工具已经够强大了，测试团队也是利用linux的命令采集服务器端资源，然后把消息发送到自己编写的一些资源监控工具上，其实都是利用了原生的shell命令和jvm命令来周期性采集并绘图的。

JMeter没有现成的sampler施压hessian的接口，所以我们需要利用它极具扩展性的java请求 sampler来施压hessian接口。我们查看jmeter安装目录下的lib>ext下可以发现其他多种类型的sampler。其他的种类都可以由java sampler来实现。我们只需要继承org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient该类，在runTest方法中调用hessian接口，并封装返回值即可。然后把工程打成jar包，放到jmeter安装目录下的lib>ext下。启动jemter，在利用java sampler就可以定为到我们编写的扩展测试程序了。

在压力测试过程中，包括两部分的资源检测，jvm的资源占用。一般利用jdk自带工具集
1、jps

    常用的几个参数：
    -l  输出java应用程序的main class的完整包
    -q  仅显示pid，不显示其它任何相关信息
    -m  输出传递给main方法的参数
    -v  输出传递给JVM的参数。在诊断JVM相关问题的时候，这个参数可以查看JVM相关参数的设置
2、jstat - Java Virtual Machine Statistics Monitoring Tool

    jstat [Options] vmid [interval] [count]
    Options -- 选项，我们一般使用 -gcutil 查看gc情况   还有其他选项如：
                  -class  -compiler -gc -gccapacity -gccause -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcpermcapacity -gcutil -printcompilation
    vmid    -- VM的进程号，即当前运行的java进程号
    interval-- 间隔时间，单位为毫秒
    count   -- 打印次数，如果缺省则打印无数次
    -----------------------------------------------jstat -gcutil [pid] 输出解释

    S0  -- Heap上的 Survivor space 0 区已使用空间的百分比
    S1  -- Heap上的 Survivor space 1 区已使用空间的百分比
    E   -- Heap上的 Eden space 区已使用空间的百分比
    O   -- Heap上的 Old space 区已使用空间的百分比
    P   -- Perm space 区已使用空间的百分比
    YGC -- 从应用程序启动到采样时发生 Young GC 的次数
    YGCT-- 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
    FGC -- 从应用程序启动到采样时发生 Full GC 的次数
    FGCT-- 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
    GCT -- 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
   


3、jhat - Java Heap Analysis Tool 用于内存快照文件的分析，当然还有很多类似工具
4、jstatd - Virtual Machine jstat Daemon
5、jinfo - Configuration Info
6、jvisualvm - Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool
7、jconsole - Java Monitoring and Management Console
8、jmap - Memory Map jvm内存分析工具，得到最普遍的使用。
        jmap -histo <pid> b.log  输出内存类占用，对比各时段的内存类，可方便知道回收情况和占用情况。
        jmap -dump:format=b,file=heap.dump <pid>  输出内存快照，可用许多开源工具分析内存快照。
        jprofile 太耗内存，如果静态分析能得出结论的可避免使用

9、jstack - Stack Trace 打印线程的堆栈跟踪信息

10、btrace -sun提供的检测工具，很好很强大，用于检测函数耗时等，微浸入。

而服务器端的资源监控多用Linux的shell命令如：top，free，vmstat，iostat，uptime等，详细用法不累述。



本次测试过程中遇到的几个误区和犯的错误：
1、jmeter关于线程组的线程数和ramp-up值的设置，如果设置ramp-up为1秒，线程数为10，我错误的理解为这就是一秒内的请求量。其实是jmeter一秒内启动了10个线程，这10个线程分别发送请求，知道服务器端返回后，再次发送。

这个错误的理解直接导致我们的一个异步接口（接口把数据保存在一个无上限queue中，另外起线程来消费）在压力测试过程中，被压垮，以为是内存泄露问题，其实只是我们的服务器没能力处理这样一个数据量。

2、在一个日志处理模块中的生产和消费者模型中，产生的线程过多。后经过配置修改了消费者和生产者的比例。但是在定位问题时，产生很多困难，因为不知道是什么线程出现这么多。程序中所有的线程必须命名才方便工具的观察，需要开发中规范和定义好。

3、对于任务类型的性能测试没有返回值，我们怎么观察任务处理一条记录的时间，或单位时间内处理记录的条数呢？开发人员习惯在源代码中去修改，并做trace，更好的方法是采用btrace工具来跟踪方法的进出。它在监控方法的耗时，查看某些方法的参数值，监控内存使用情况等一系列场合中使用。

4、开发错误的理解 org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor 类的corePoolSize和maxPoolSize和queueCapacity三者的关系。原以为corePoolSize是启动时变初始化的核心线程数，如果还有任务需要执行，那么就会新建线程到线程池中，直到达到最大maxPoolSize的大小。然后放不下的任务才浸入queueCapacity中存储。而实际情况确是：任务到达corePoolSize之后，就放入queueCapacity的queue中了。造成我们的配置错误，引起串行的任务执行。


的确在开发功能测试中没有发现的问题，通过性能测试暴露了出来。除了这些bug之外，我们还确认了我们接口的性能，任务的性能和稳定性。