压测背景：项目上线需要知道有多少个用户和导购能同时在线，并且正常使用
场景分析：先进行用户端连接服务器，然后导购端在链接服务器，然后开始拉取视频列表，最后接听视频
脚本设计：设置三个线程组
-
- 线程组一，负责用户端链接socket, 并且发送请求视频通话请求
-
- 线程组二，负责导购端链接socket, 并且发送心跳
-
- 线程组三，负责拉取视频和接听通话
-
- 三个线程组的执行先后顺序是，线程组一和线程组二同时执行，线程组三等待5秒之后再执行
一轮测试：只测试了用户端去连接socket , 结果：超过50个以上的线程，就会导致报错
于是进行排查，主要去修改服务器的连接数
二轮测试：任然只是去测试用户端去连接socket,结果：修改的配置不起作用
于是开发加了资源，多加了一个cpu
三轮测试：任然只是去测试用户端去连接socket,结果：加的资源不起作用
于是开发开始排查是否是网关的问题，
四轮测试：任然只是去测试用户端去连接socket, 这次是换成ip加端口去测试，结果：并发可以达到800用户
于是初步把问题定位在网管这里，提议把把启动线程的时间延长，这里主要是因为域名解析和到达网管服务之前，有一个防火墙，防火墙机制会去检测一些奇怪的请求，例如同时大量来自同一ip请求过来的访问，
会被视为恶意攻击！！！！
五轮测试：任然只是去测试用户端去连接socket, 这次是用域名去测试，不过启动线程了时间变成了800秒，结果：先后在800秒内，同时能有800的用户访问
六轮测试：这次同时测试了用户端和导购端，结果：在500个用户的情况下，启动10个导购，都报错了
于是定位导购端代码是不是有问题（这时候已经排除了网关的问题），开发把一个同步的操作改成了异步
七轮测试：这次同时测试了用户端和导购端，结果：在500个用户的情况下，启动50个导购，能顺利平稳的运行
至此，整个压测其实持续了三天，经过了几十轮的调整，优化，最终能得出一个合理的压测结论。
感想：这次压测能进行的比较顺利，主要是因为开发高度配合，定位问题，甚至请求到了安全部门的人在配合，通过这次压测，掌握如下知识
- 如何使用jmeter进行websocket协议接口的压测脚本编写
- 了解了在遇到性能问题是，开发是如何排查问题的