生产环境出现了仓配订单丢单情况，于是通过日志排查，发现有少量订单在插入数据库时连接失败。在更改了mysql连接池的最大连接数后，补丁部署到uat中。决定做一次压测，来测试仓配时效明细数据写入数据库是否出现写入失败的情况。

　　经过对现有业务数据量监测，连续30天内有近112w仓配订单数据，每条订单在下单后有揽收、交件、装车、卸车、出中转、分发、签收等10个请求。根据性能测试方法论中的重要参照二八原则，80%业务需要能够集中在20%时间内完成，即订单数=1120000*0.8=896000，并发数为896000*10=8960000，时间=30*0.2*24*60*60=518400s，预期qps为8960000/518400=17.28。因此本次压测须满足qps>=18。

　　采用测试工具jmeter，通过http协议post方式发送冷配订单创建请求，并依次通过订阅、揽件、交件、装车、卸车、出中转、分发、异常签收、正常签收等流程。使用计数器控制下单单号连续自增，使用临界部分控制器保证各请求按照指定顺序依次发出。使用setup线程组前置完成下单、订阅和揽件记录的顺序请求，仓配订单轨迹扫描线程组控制后续单据扫描流程的按顺序请求。

测试环境的服务器:

　　在不断加大线程数，从10-20-50-100-200-300，请求都是100%成功，加到300理论上已经远远大于生产上并发了，就不再加了。在300线程数执行3次均获得100%成功后，即终止压测。

　　在同时满足300个订单下单及后续轨迹扫描共3000个请求并发情况下，请求100%成功,tps达41.21，大于预期18。

　　轨迹的扫描节点过多，接口返回也简单，就没必要做断言，直接查看结果树和聚合报告就行。观察系统中下单时间在2022-08-11 18:00:00到2022-08-11 18:05:00中的300个订单轨迹均接入系统，无遗漏。单号从888888880000771到888888880001070。

此外，在单用户登录系统的响应时间，测试过程中发现响应时间RT普遍在2.5s以上，在业界新的1-3-5秒的原则下，仍存在不小的优化空间。在开发同事对查询响应进行优化后，RT普遍在200ms以内，调优效果显著。

调优前:

调优后：

　　至此，基本能得出结论，测试环境支持300以内的并发，对该部分并发数的请求响应优秀，我们的系统现阶段在300并发下达到了100%的可用性。在实际应用中，我们的系统很少会遇到这种强度的并发。因此我们认为我们的仓配时效轨迹接入在压力测试下表现良好，符合预期目标。