CardioLog Analytics 压力测试的那些压力

去年我们公司承接了实施CardioLog Analytics的项目，用于做SharePoint 2019企业门户网站访问的数据收集与分析。虽然产品不是我们自己做的，可是我们承诺满足如下压力测试指标：

所有浏览页面最慢的95%的访问时间的平均数不超过三秒钟。

三秒钟，我们过去做压力测试，五秒钟都很难达到，而且还是90%的平均数。

我们用来做压力测试的工具是WAPT Pro，测试版并发用户最多20个。

我们遇到的第一个问题就是WAPT Pro在普通客户端上用不了，无法捕捉页面访问操作。那怎么办呢，我想起SharePoint的供应商应该做过这个事，我问他们咋做的，他们说他们用Visual Studio，于是一阵子捣鼓，学会了用Visual Studio, 也说服客户让我们用同一台机器进行测试。

仿真了20个用户进行初测，最差性能指标页面居然有8到10秒。我一下子傻眼了，要知道服务器的配置都是16个CPU，32G甚至64G的内存。非常不可思议的是我本地性能一般的服务器的最差也可以达到6秒。那是不是服务器配置有问题呀？网上一通找，有人说防病毒软件也可能会让IIS变得很慢。我们询问服务器团队的防病毒软件有没有装让IIS变得很慢的插件，答案当然是没有下文了。我又问SharePoint供应商了，你们压力测试的时候遇到啥问题了吗？人家说啥问题没有呀。

为了降低难度，我们打算在并发用户数上面做文章，20个不行，10个行不行？我们先问用户，总用户数多少？用户说50个，那我们说20%的并发用户，10个行吗，用户说以后我们用户还会增加，20个行不行，我们说20个不需要吧，用户说那你们看着办，反正10个不行，我们左思右想说12个怎样？用户答应了。

另外就是在测试工具上做文章，我用WAPT Pro和Visual Studio进行比对的时候发现还是WAPT Pro给出来的性能更好一些，大概快了1到2秒，这很重要啊。于是强烈要求用户让我们用WAPT Pro，在服务器上一装，一测，UAT的最差性能指标大约是5到6秒的样子，总算正常了。再继续测Production，就是之前20个用户8到10秒的，用户数减少，又用WAPT Pro来测，性能有提高，但是还是离3秒的指标有差距。于是开始看服务器的CPU占比，很高啊，有60%。把IIS重置一下，CPU的占比下降，保持一个比较低的水平。这时候启动测试，性能不错，最终90%的平均数低于3秒，可以交差了。

别忘了我们承诺的是95%的平均数，90%的低于3秒，95%肯定要高一些的，因为又加入了最慢的5%。修改统计的百分比变成95%再测一遍，也是如履薄冰地测完了，还是3秒以内，不过有好几个接近3秒了，哪里再多一点就超了。

 可是事情还没完，之前我们做的都是在Production上面做的，我们最终的测试要在UAT上面做，在服务器配置没达到要求的时候，我们测了一下，3秒达不到。昨天用户加上服务器的顶级配置，又是心惊胆战地开始了测试，一上来就6秒，过了10分钟有所下降，可是离3秒还有差距啊，20分钟之后，不出所料3秒超了，不通过。

之前一直使用固定用户数，然后尝试一下从0用户开始，每10秒钟增加5个用户，到20秒的时候再增加2个。初始压力减少了，看看能不能开出一个好的结果，总算有一次看着数据还行，有机会，18分钟的时候还是3秒以内，结束了，高高兴兴地保存结果，最后发现一个3.05的，就是最后一两分钟出现了一个3.88的，结果就变成这样了。

还是看CPU占比，有达到60%的时候，于是IISRESET，预热之后继续测，结果都不好，3.05都达不到，好几次看着没希望的都提前停掉，关键是中间出现3以上的太多了，几乎不可能低于3秒，都快绝望了。最后进一步尝试关掉CardioLog自己的服务，时间已经到了下午5点，不知道是因为快下班了，使用的人少了还是怎样，测试跑起来的时候，CPU占比没增加太多就在20%左右，看看实时数据，还可以，最终最差数据停留在2.8，10个区间，超过3秒的只有两个，总算可以真正交差了，算是给自己的一份圣诞大礼吧。

从这次测试来看，要想保持非常好的性能，不能出现峰值，我之前测的时候，多次出现峰值，还有4秒5秒的，这种肯定是过不了的。而峰值的出现跟服务器的CPU占比息息相关，一定要保持在50%以下，另外要选择服务器非繁忙时段进行测试，实在不行半夜三更也行啊，其他的就听天由命了。