性能测试系列十 压测工作开展中
性能压测系列文章
调试好脚本，准备好环境，我们就可以开始压测了。那么在压测中，有什么常见的问题以及，我们需要做些什么呢。
•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增加四行：= 1= 1= 1= 30
对于全链路还是单接口的压测呢，我的观点呢，先单接口压测，在单接口压测都无法满足的时候，全链路压测 出现问题会更多，直接单接口压测，问题陡增，会减少开发者的信心，同时也会造成对结果的怀疑，单接口的压测满足的情况下，再选择多接口压测，然后全链路压测。这样采用循序渐进的方式去完成这些工作，把大事分割模块，小步快跑的方式去完成压测的工作。
小黑屋压测，为什么要这么做。高效的沟通，高效的协调。我们可以看到不管是双十一，还是春晚红包，还是618，各个公司都会搭建相关的作战室，为什么，因为最高效，最容易协调。所以小黑屋压测，或者大家聚集在一起。有时候，可能你的数据给到开发，开发说我怎么没有这么感觉，压测的时候在一起，有时候，出现问题来，开发就在，直接看指标，看数据，拉去相关日志，排查分析问题，更加简单方面。
准备预案，我们一定要有一定的预案，防备突发情况。预案我们可以前期，进行演练。做到心中有数。预案可以随时启用，启用就能收到效果。作为最后的保障。做好预案，对预案进行验证。
压测的优化，要同步业务，因为有时候为了高并发呢，可能会开发一些轻量级别的接口，可能是参数的增加，走轻量接口，这时候，要同步给业务同学，这里不止是业务开发，还有业务测试，还有相关的产品。因为有些优化可能出现没有测试充分之类的问题，一定要和相关的人员同步。
记录压测数据。准确的记录，形成wiki文档等，可以长期保存的，一遍查阅，不管是压测中遇到的问题，解决方式，还是压测的数据。都要记录。形成团队的文档，做到有源可溯，同时也方便以后的查阅。
压测中，会遇到很多问题，大家一定要坚持，而且有时候 可以群策群力。有好的想法，就可以提出来。压测的工作，往往是紧张的，有时候工期紧，有些时候排查难度大。无论遇到什么样的问题，团队之间及时沟通，各个工种坚守自己的责任。一起努力，完成相关的测试工作。