性能测试是一件看起来不简单，操作起来确更困难的事情，我认为，每认真做一次性能测试，一定会有不同收获，而每次性能测试暴露的问题，现象都不是仅仅涉及Java，tomcat这么简单，简单说是光会写代码是无法做好性能测试的。
　　那么，趁着这次性能测试的机会，重新梳理下对linux，网络IO等基本功的认识已经性能瓶颈的定位分享下自己的心得。
　　背景：
　　本次性能测试的目的是测试使用公司内部RPC框架开发的一套接口的性能，目的是准确的拿到接口的性能指标，当然，我也想换个角度去看待代码，比如，从性能或者对操作系统友好的角度，首先略过1万字的环境搭建过程，其实，性能测试是件非常考验细心程度的活，需要你对整个组网环境，调用关系，业务逻辑非常清晰，能正确识别出压力机，应用服务器，数据库服务器，缓存服务器各自的职责，并在可能的情况下压榨其性能极限，以及清楚明白可能对其性能造成影响的命令和操作（比如jvm启动参数中，大部分日志打印相关参数，关闭即时编译，调整GC分带的大小和比例等等）。
　　其次，还需要你能清楚本次测试程序的核心流程，业务逻辑，尽可能的将一些非核心的组件可能造成的影响去除掉，比如，本次测试的是RPC接口的性能和业务处理的效率，而相应涉及到的分布式缓存，数据库，则不是本次测试的重点，因此，组网时，应该尽可能将分布式缓存，数据库等机器与应用服务器放在同一个局域网网段内甚至同一台机器上，保证不会因为他们的表现而直接影响测试目标测试结果。总之，Mock掉一切非核心，不相关的因素。
　　测试工具/命令
　　因为是对RPC接口做测试（而非HTTP接口），使用loadRunner等测试工具无法满足要求，所以在测试工具的选择上，使用了jmeter。这是一款java实现的性能测试工具，使用方式是，继承他的AbstractJavaSamplerClient抽象类，在其runTest方法中编写测试用例即可在Jmeter的客户端中发现测试jar包，从而配置线程数后开始性能测试。具体使用请google之。
　　在压力机上部署好jmeter后，多线程开始执行测试用例，用例开始向应用服务器发送调用请求。这个时候设置的并发数应该尽量让压力机的CPU达到一个较高的值，比如 70%左右，jemeter提供了预热功能，必要时候可以使用预热功能将压力慢慢加大。
　　下面，我们借这次性能测试的机会介绍几个很好用的命令，启动后可以先到应用服务器上使用top命令，观察其CPU利用率，按数字键1，详细查看每个CPU的利用率。 理想情况，这个时候应该可以看到一定的压力。
　　也可以使用 vmstat命令，比如： vmstat 1  30 标示，每隔一秒打印一次统计信息，统计30秒。
　　打印结果类似：

　　通常主要关注r 和b 分别代表运行队列的数量和阻塞个数。理想情况应该是r比较多，b没有。
　　具体vmstat命令的结束可以看:http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html
　　关注完CPU，还可以使用iostat命令 查看IO的情况，命令格式类似vmstat， iostat 1 30 表示同样的意思:每秒打印一次统计信息，打印30次后退出。
　　这里使用iostat -dx 1   每隔一秒打印一次磁盘的详细信息  具体可以参看这里：http://www.cnblogs.com/peida/archive/2012/12/28/2837345.html

　　可以看到io并不频繁。都是在很低 的水平上，因此IO应该不是此次性能测试的瓶颈所在。
　　看完vmstat，iostat，如果都不是处在很高的水平，下一个应该优先看网络，是的，对于linux还有一个netstat，使用方式与前两种不同，但是功能同样强大，可以列出应用服务器上所有tcp连接的详细信息。通常情况，可以观察下应用服务器上的TCP连接数，连接状态是否正常等来判断应用是否运行正常。
　　很好用的工具，动手输一下，你会知道它的功能了。
　　测试目的
　　一般测试的目的有两个：
　　1. 是获取接口的性能，常用TPS，延迟，QPS等衡量。
　　2. 是通过性能测试，找出性能瓶颈，定位并优化它。
　　因此，性能测试必须要满足的一个原则是，要么把压力机跑满，要么让应用服务器的某项指标跑满，之所以说某项指标，是因为，根据应用的不同，例如：CPU密集型应用，IO密集型应用，相应的，性嫩测试的时候应该尽量让CPU利用率或者IO利用率达到一个较高的水平。
　　如果有一项指标没有达标，那性能瓶颈的定位过程来了。