本文已参与「新人创作礼」活动，一起开启掘金创作之路。
踩坑记录
之前参与的压测工作都是执行者，根据别人的方案，别人的想法去执行压测脚本即可，没有主导过大型项目的压测，所以这次在压测过程中也算是磕磕绊绊，还好开发同事是个有经验的老司机，遇到的问题基本都能帮忙解答
无法达到预期并发
最开始进行压测的并发设置从80-200时，服务相关接口请求量基本维持在一个量级，但是服务器的CPU内存等维持在一个很低的数值，反倒是压测机的CPU 不管设置多少并发，CPU都是100 % 一开始以为发压机的原因，因为申请的机器是容器环境，不是实体机，认为申请的服务器资源可能存在虚标。
针对这个猜想，我重新申请了发压机，使用分布式的方式进行加压。但是采用这种方式后还是无法将并发提高。所以这个猜想不成立
后面将情况反馈给研发同事，研发同事说，我们的请求是通过运维团队的“高防”服务的过滤后转发到我们服务的。有可能是这个服务的性能不好。
对于这个猜想，我们调整了请求的方式，先使用单机，直接请求服务的单台IP，发现单台IP能统计到的请求量都远大于之前的请求量
好吧！就是这个高防服务的原因。但是我们的系统是海外的系统，海外的情况很复杂，黑产也比较 猖獗，我们必须要借助高防服务来帮助我们拦截掉一部分的请求。
最后在运维的协助下，我们重新配置了一个本地域名，通过这个域名去请求的话，就能绕过高防服务，而且这个本地域名请求用的是Http，相较于https也有一定的性能提升。这里插入两个知识点，一个是http和https的，还有一个就是本地域名访问的原理
- HTTP 和HTTPS 的区别
HTTPs链接和HTTP链接都建立在TCP协议之上。HTTP链接比较单纯，使用三个握手数据包建立连接之后，就可以发送内容数据了 它也采用TCP协议发送数据，所以它也需要上面的这三步握手过程。而且，在这三步结束以后，它还有一个SSL握手。 所以，HTTPs肯定比HTTP耗时，这就叫SSL延迟。
- 域名绑定
对于一些经常要访问到的网站，我们可以通过在Hosts中配置域名和IP的映射关系，这样当我们输入要访问的虚拟域名，计算机就能够很快地解析出IP，而不必请求网络上的DNS服务器。
这样就可以直接验证后端服务的相关性能，而不用去排查网络问题
服务器没有达到瓶颈
越过一号坑后，我们将一些性能较好的接口TPS已经压测到2W+了，但是在服务器和压测机性能指标都还没有达到瓶颈时，却再也压不上去了。
这时我们又引入了另一个猜想，那就是机房网络上限。为了验证这个猜想，我们直接在本地又启动了一个线程，和远程机房的压测脚本同时请求服务，发现请求量确实又增加。
最后求证运维同事，运维同事帮忙查询了网络带宽后，确认是因为当地机房的网络限制，带宽已经满了，所以本地的请求就无法再提升了。
线上只能“读压测”
因为一些原因，系统无法将一些生产数据隔离，导致线上无法进行“写压测”，如果系统有相关支撑的话，理论上我们可以在生产环境加上一些白名单，或者在请求中添加一些特定的参数，让压测产生的数据进入一个与生产环境隔离的数据库，这样就能在原有服务器资源的条件下，模拟“写压测”。 我们还可以回放线上流量，更加真实的模拟线上的请求。当然流量回放也有很多问题需要去面对，比如登陆失效，数据降噪等问题。我认为这会是后续压测的一个主流的方向吧！
临近上线，发现活动页面漏测了
在我们将压测服务器释放并且将压测报告整理汇报之后，发现运营新配置的活动页面有两个重要的接口没有压测，这个最后只能再临近封版前再补充一轮压测。
这个情况当时确实很无奈，因为当时获得的信息是活动页面为首页，然后运营通知有个活动落地页面，最后只能查看页面接口再分析哪些接口需要压测
这个也算是信息没有及时同步，导致很仓促，好在结果还算OK。这里算是经验教训吧，一定要及时同步信息，不关是不是你的疏忽，提醒相关同事注意事项也是很有必要的。
总结
经过这次大促的压测，自己对压测和系统 的理解也算是深入一些了，当然这还远远不够，我认为一个压测工程师的话，不仅需要发现系统 的性能瓶颈，更重要的是针对这些性能的瓶颈，给出改进的意见。
