开头
写这篇文章的目的其实有2个：
1.总结自己的工作收获工作中的经验
2.也是应我离开公司后，测试小伙伴们的诉求，给他们一些指点吧（杨霞，雅洁，高巧，还有雪晴，希望此篇文章能给你们提供一些帮助，助你们在测试的道路上越走越好）
好了，废话说了很多，回归正题，性能测试的工具有很多，但是总体还是思路和设计主导，再带入工具。此次我将依据工作中的实际场景，总结一下性能测试怎么入手
分类
性能测试主要分为几个大块
1. 服务器
2. 数据库
3. 中间件
4. 负载均衡
以上是需要测试到的地方
服务器与场景设计
计算TPS
任何系统都是需要人来使用的，那么有一个比较通用的公式能够很好的依据系统的预计使用压力，来设计我们的场景
系统的压力指标最直接的也就是TPS（系统吞吐量），按照二八原则，公式如下：
TPS=日交易次数*80%/（日开放的交易时间秒*20%）
举个例子：一个系统每天业务请求有2百万次，24小时开放。 那么对应的TPS为：2000000*80%/（24*3600*20%）= 3.7 次/秒
如果对系统性能需求较为严苛，则可以遵循一九原则
设计场景
在知道系统吞吐量以后，可以开始设计实际使用场景
1）单交易目标TPS=脚本配置占比*总目标TPS
2）单交易并发用户数=单交易目标TPS*ART
3）实际并发用户数=单交易并发用户数上取整
4）交易间隔时间=实际并发用户数/单交易目标TPS
由此设计出单业务TPS，单交易并发用户数，交易间隔时间。
场景运用
单交易最大压力：
上面我们已经获得了单业务的吞吐量，按照单业务的并发量开始加压，压力不能小于单业务的吞吐量，并试探服务器的最大承受极限
服务器最大资源阈值达到系统最大处理能力时，为最大承受极限，最大tps和最大并发数依据最大处理能力填写，运行时间为半小时到一小时
单交易稳定性：
单个请求保持最大压力，持续12小时，测试系统稳定性
混合场景稳定性：
混合场景则按照计算的实际最大总吞吐量，按照百分比分配的单场景混合脚本运行，服务器指标和单交易稳定性一致
业务指标：
其中业务指标也需要考虑，如服务器硬性指标和业务指标任何一项未达到，则不合格
至此，场景设计完成。
数据库
数据库压力在性能测试中也至关重要，比如MySQL连接数，表的大小，insert和查询时间速度等
就用MySQL为例
通过分析，在一定数据量下，针对数据库的基本操作的时间不能超过上图范围
至于数据库工具，大家可以用Jmeter提供的现成的JDBC来进行测试
当然如果基于python技术栈，也可以自己写个时间方法，查询方法来的更快更灵活，并且可通过matpoltlib绘制直观的趋势图
同样数据库服务器的系统资源同样重要
中间件
中间件此处以Tomcat为例
其中JDBC连接等待数，线程繁忙率比较重要
JDBC连接等待数和繁忙率：http://ip:port/probe
通过tomcat的probe工具，放入webapp下，输入对应的ip地址，对性能进行监控（此处不详细介绍probe，自行查资料）
负载均衡：
负载均衡有很多工具，用的比较多的应该有nginx反向代理。
此处我们要关注的不是nginx怎么配置与怎么工作，很简单，此处我们只需要知道输入和输出，并且对比
在最大TPS下，使用服务器性能监控工具（nmon等工具，自行查资料），对比多服务器之间的cpu使用差异率即可
最后：
大体的性能测试入手与思路介绍完成，具体应该根据实际业务情况，使用环境和工具做进一步的详细设计。
locust，sql性能等，完全可以自行写适合公司的框架来进行性能测试（个人建议）
如要转载，请注明出处