性能测试系列十 压测工作开展中

性能压测系列文章

性能测试系列一（性能测试基础知识）

性能测试系列二 何时介入性能测试

性能测试系列三 压测方式简单总结

性能测试系列四 压测指标的来源

性能测试系列五 压测常见的关注指标以及监控分析工具

性能测试系列六 评估压测量

性能测试系列七 工具选择

性能测试系列八 梳理业务场景 搭建测试环境

性能测试系列九 选择压测环境，编写调试测试脚本

调试好脚本，准备好环境，我们就可以开始压测了。那么在压测中，有什么常见的问题以及，我们需要做些什么呢。

•1.关注业务链路的各个性能指标(运维的监控平台，测试的结果展示平台)
•2.采取分布压测等压测方式
•3.进行摸高并发，单接口，混合接口压测，全链路压测(需求初期确定)
•4.实时关注指标，记录压测数据
•5.及时反馈压测结果。
•6.及时沟通，及时跟进，小黑屋压测（高效）
•7.压测优化及时同步业务
•8.压测过程数据要准确记录，方便追溯
9.准备预案

首先呢，我们要看压测中的性能指标，有运维搭建的监控平台，也有我们自己搭建的结果平台。如果运维没有相关的平台，我们可以申请运维去搭建这个，如果没有专业的运维的团队呢，我们需要自己去搭建我们的监控。可以利用nmon2influxdb+grafana，或者zabbix+Grafana来搭建相关数据的收集展示平台。当然，也可以选择其他的工具来搭建。如何搭建，后续的将会分享。搭建完毕后呢，就可以成为一个简易版本的监控了，当然了，这些监控都是一些开源的统一的，我们还可以利用python等，根据自己的需求做些开发。但是在自研中，一定要注意到，自研工具，自身带来的性能问题，而且还要进行一定的调试，在短期内要做完事情，还是利用 现有的成熟的工具来完成。我们利用jmeter来做压测的时候，那么我们的数据结果可以使用Jmeter 的Backend Listener来给InfluxDB上传数据，部署InfluxDB环境，搭建Grafana作为展示的平台即可。InfluxDB的数据的存储可以增加一定的时效性，比如存储一周即可，因为压测会产生大量的数据。在我们搭建完毕，进行调试，看数据是否可以进行上传，Grafana的数据是否可以正常展示，如果想要做一些定制性的，自己可以在Grafana 图标中进行对应sql的编写即可。调试完毕，就可以进行相关的压测。

在前面，我们已经确定了，我们压测的方式，是分布式还是单机，我认为，量不大 可以用单机，在选择机器的时候，可以选择linux 系统作为压测机。在windows上面，超过700有时候会报一些windows的错误，网上基本答案无法解决。linux 作为压测机器很合适，如果端口不够用，可以修改下端口的回收时间间隔。可以参考下面的配置，当然了，实际的压测还要根据具体的情况而来。windows系统可以作为我们调试脚本来用。考虑到UI界面可能对性能的影响，简易在压测的时候，选择无gui的方式来进行压测。使用命令行的方式，前提要配置环境变量，或者在前面加上路径。

编辑/etc/sysctl.conf文件
vi /etc/sysctl.conf
增加四行：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30

对于全链路还是单接口的压测呢，我的观点呢，先单接口压测，在单接口压测都无法满足的时候，全链路压测 出现问题会更多，直接单接口压测，问题陡增，会减少开发者的信心，同时也会造成对结果的怀疑，单接口的压测满足的情况下，再选择多接口压测，然后全链路压测。这样采用循序渐进的方式去完成这些工作，把大事分割模块，小步快跑的方式去完成压测的工作。

关注压测的监控指标，看一些监控的指标和压测的数据，以及有监控的要看下监控是否正常，压测的时候，是对很多监控的一个更好的检验的时候，因为在压测，我们很好达到性能监控的阀值，所以这样也是对一些之前搭建的监控，没有校验过的一个校验。关注我们初期制定的标准，超过标准，我们要准确的记录，一定要及时准确的记录我们的压测的数据，压测的结果。对于压测的结果，我们一定要及时汇总，及时沟通。

小黑屋压测，为什么要这么做。高效的沟通，高效的协调。我们可以看到不管是双十一，还是春晚红包，还是618，各个公司都会搭建相关的作战室，为什么，因为最高效，最容易协调。所以小黑屋压测，或者大家聚集在一起。有时候，可能你的数据给到开发，开发说我怎么没有这么感觉，压测的时候在一起，有时候，出现问题来，开发就在，直接看指标，看数据，拉去相关日志，排查分析问题，更加简单方面。

准备预案，我们一定要有一定的预案，防备突发情况。预案我们可以前期，进行演练。做到心中有数。预案可以随时启用，启用就能收到效果。作为最后的保障。做好预案，对预案进行验证。

压测的优化，要同步业务，因为有时候为了高并发呢，可能会开发一些轻量级别的接口，可能是参数的增加，走轻量接口，这时候，要同步给业务同学，这里不止是业务开发，还有业务测试，还有相关的产品。因为有些优化可能出现没有测试充分之类的问题，一定要和相关的人员同步。

记录压测数据。准确的记录，形成wiki文档等，可以长期保存的，一遍查阅，不管是压测中遇到的问题，解决方式，还是压测的数据。都要记录。形成团队的文档，做到有源可溯，同时也方便以后的查阅。

压测中，会遇到很多问题，大家一定要坚持，而且有时候 可以群策群力。有好的想法，就可以提出来。压测的工作，往往是紧张的，有时候工期紧，有些时候排查难度大。无论遇到什么样的问题，团队之间及时沟通，各个工种坚守自己的责任。一起努力，完成相关的测试工作。