有机会做了一次性能测试工作，主要是预研性质的工作。开发人员有必要再提交给测试做性能测试之前，做一次比较粗糙的性能测试工作。
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。其他的种类都可以由javasampler来实现。我们只需要继承org。apache。jmeter。protocol。java。sampler。AbstractJavaSamplerClient该类，在runTest方法中调用hessian接口，并封装返回值即可。然后把工程打成jar包，放到jmeter安装目录下的lib>ext下。启动jemter，在利用javasampler就可以定为到我们编写的扩展测试程序了。
在压力测试过程中，包括两部分的资源检测，jvm的资源占用。一般利用jdk自带工具集
1、jps
常用的几个参数：
-l输出java应用程序的mainclass的完整包
-q仅显示pid，不显示其它任何相关信息
-m输出传递给main方法的参数
-v输出传递给JVM的参数。在诊断JVM相关问题的时候，这个参数可以查看JVM相关参数的设置
2、jstat-JavaVirtualMachineStatisticsMonitoringTool
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上的Survivorspace0区已使用空间的百分比
S1--Heap上的Survivorspace1区已使用空间的百分比
E--Heap上的Edenspace区已使用空间的百分比
O--Heap上的Oldspace区已使用空间的百分比
P--Permspace区已使用空间的百分比
YGC--从应用程序启动到采样时发生YoungGC的次数
YGCT--从应用程序启动到采样时YoungGC所用的时间（单位秒）
FGC--从应用程序启动到采样时发生FullGC的次数
FGCT--从应用程序启动到采样时FullGC所用的时间（单位秒）
GCT--从应用程序启动到采样时用于垃圾回收的总时间（单位秒）
