jmeter测试总结

一次性能测试的总结

相关推荐：Apusic应用服务器的性能调节_JVM优化

Apusic应用服务器作为企业应用的运行平台，系统的性能非常重要。当应用对性能的要求比较苛刻时，就要考虑是否需要改变系统的缺省设置来提升服务器的性能。首先应该考虑系统的硬件环境（CPU主频高低、内存大小、硬盘转速及网络传输速率等）是否能满足应用的需

有机会做了一次性能测试工作，主要是预研性质的工作。开发人员有必要再提交给测试做性能测试之前，做一次比较粗糙的性能测试工作。 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 Daemon5、jinfo - Configuration Info6、jvisualvm - Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool7、jconsole - Java Monitoring and Management Console8、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之外，我们还确认了我们接口的性能，任务的性能和稳定性。