一个系统在完成功能测试之后，需要预估公网用户量，系统的承受能力以及稳定性，这个就是性能测试需要给出数据指标的事儿。 系统的性能测试该如何进行？本文写的观点不一定正确，有误请指正，勿打脸，多谢。

一个请求从施压端出去，要通过网络达到服务端，然后系统处理，连接数据库，数据库读写，再将信息返回给系统，系统通过网络传输给客户端。其中网络传输过程中，cdn解析，路由trace，网络带宽，网速等等有决定性，而且传输的数据量多少，数据库检索的结果量的多少等等，对于监控系统的Network I/O影响作用比较大。code逻辑处理中，如果使用到大量的计算或者资源调度等，对监控系统的CPU负载影响比较大；此外就是Disk I/O的方面，对本地文件系统的操作过多的话，Disk I/O相关的磁盘读写则影响比较大。还有swap等等，上诉所说的就是所谓的CPU密集型或者IO密集型应用系统的特点，也是在监控服务端分析服务器负载的一些基础，根据不同的表现，分析系统和code中的瓶颈，进行对应的优化和调试。

测试case的设计&数据指标的确定

对于http接口而言，需要了解接口的参数行为，针对不同的数据库读写与参数要求设计接口。例如：公网用户登录时，有些用户仅仅只读数据库，而有些用户既读又写数据库。这两种case则要分开压测，得到的系统性能指标也会有所不同。 数据指标对确定是需要对于系统到达一个什么样的数据后，即为可以接受的标准。比如：对于响应速度和正确率要求非常高的接口，可能需要确定为99百分位的响应速度在500ms以下；而对于实时性要求没那么严苛的接口，可能99百分位的响应速度为2s也是可以接受的。这些都是根据具体的系统而定。后续的压测数据均以这个指标为标准。

这里给出的99百分位的响应时间，而不是平均时间。跟平均工资一个道理，不多说。 除了响应时间，还有一个概念：吞吐量。很多文章有说QPS和TPS的，即transactions per second和requests per second。这是反映系统处理能力的指标。

施压工具的选择

Jmeter,开源工具。LoadRunner也是性能测试的名角儿，但是工具总是大同小异的，哪个用的惯用的爽就用哪个，用透后，其实工具都是一样的，用来解决问题。现在jmeter还只是处于会用状态，继续努力。 jmeter性能测试的时候，对于并发量的施压过程中，ramp_up的时间有疑问。譬如：为什么100并发，一秒内启动，持续5s，结果sample不是500个？为什么100并发，循环5次，500个sample处理完成后需要10s？等等之类等问题。这两种情况其实就是jmeter提供给的两个不同的性能压测方式。 性能测试：有刺探系统峰值的压测；有找到系统最优负载的并发量测试；有所谓的浸泡测试；大家可以在google上搜搜spike test，stress test,load test，soak test等等. 对于疑问中的第一种：并发量多少，持续多久时间，该种压测是为了根据并发量的增加，得到系统处理能力的吞吐量和响应时间的坐标图形，得到系统处理能力最优的并发量区段。 疑问中的第二种：偏向于对系统的峰值刺探，第1000ms时刻，100个并发请求已发送，第2000ms时刻，200个并发请求已发送。此时，如果系统的吞吐量为50q／s的话，那么第2000ms时刻，系统已有150个请求等待处理了。此时如果是第一种情况，那么jmeter的请求发送可能是在第2000ms时刻，新启动的并发请求为50个，也就是第2000ms时刻，系统有100个请求等待处理。

机器硬件配置调优

硬件配置，最基础的就是limit文件限制数以及tcp相关的调优了（施压端和服务器端）。在/etc/sysctl.conf中配置net相关的tcp和udp数据。

tomcat

基础的提高JVM到栈内存；tomcat6之前版本，配置jre和PermGen的内存泄漏监听器；maxTreads、acceptCount的设置。

mysql

连接池的配置；长连接的timeout时间设置；慢查询；组合索引的效率等。

施压执行 & 负载监控

使用施压工具，选择相应的测试场景后，开始施压。施压工具会有吞吐量和响应时间的数据。jmeter工具中，安装perfMon插件以及在服务器端安装serveragent，记得得到相应的客户端数据图形以及服务端关于cpu、disk io、network io、swap等负载图形。除了服务端的负载监控，数据库端的负载监控同样重要。很多系统，瓶颈在与数据库端的读写。

瓶颈定位 & 优化调优

瓶颈的定位即表示：根据负载图像的表现判断性能在哪一环节受阻。这里有几个名词：cpu bound 和io bound应用。在最近的一次压力测试中，服务端的吞吐量一直在20个左右，性能表现十分差。在对数据的监控中发现：即使100的并发，长连接阻塞特别多，cpu使用率100。查看mysql的长连接timeout为默认的8小时，并且慢查询的时间设置为2s，虽然没有满查询日志，但是初期判断应该是满查询引起的性能瓶颈。除此之外，代码中没有对数据的连接使用完成后做及时的close操作。最后在修改timeout的时间，以及调整代码和修改组合索引后，性能上去了。 比较多的在数据库方面，线程池设定，索引问题，where使用不合理，分页读取不合理，缓存策略等等对于性能的限制以外，另一个比较常见的是Disk IO的瓶颈，比如代码中对于文本操作的不得当，log的大小不合理。 在做过大大小小的性能测试后，发现了一个错误的观点：老是在想如何提高配置与机器硬件提高系统到性能。而事实往往是提高code到质量是提高系统性能质的飞跃的基础。因为在将机器硬件配置调整最优的条件和使用的工具大同小异的情况下，框架与代码质量才是真正决定性能的要素。

数据指标

根据得到的数据，对系统性能做出结果分析与是否符合上线要求等结论，并且对于性能扩展给出相应的建议。

PS:关于性能测试，推荐看耗子叔的文章 ,虽然文章时间有点久了，但是干货还是比较多的！