1. 背景

商品线提供一个新的接口给交易线进行查询商品的标签，交易线要求QPS可以达到10,000。由于存在前期的灰度，因此暂时只选择一个sku较少的省区，前期灰度要求QPS是6000。 RT在100ms内。

请求报文除了一些固定的标识，如系统来源，电商主体，主要就是一个数组，内容是sku，一次最多是50个，返回报文中，每个sku可以携带的标签可以100个。

过程

在测试环境压力测试进行压力测试

QPS可以达到10,000,可以超过预定的6000 RT可以达到20ms内

jmeter返回的报告中，RT和QPS相当，都比较稳定

业务系统部署1台机器和6台机器返回结果是一样 QPS可以达到1,400,远低于预定的6000 RT可以平均达到140ms内

jmeter返回的报告中，RT和QPS相当都比较不稳定，QPS开始是上升的，到达一定时间后，出现了快速下降，此时RT时间上升，QPS有一定上升，但达不到一开始的波峰，RT时间下不去

通过查看业务机器的日志，发现dubbo的线程化，出现了大量的EXHAUSTED，拒绝了请求。但是什么导致线程池拒绝，进一步分板，单次线程执行时间过长，请求又过多，线程池得不到满足。单次线程执行时间过长的原因是redis的性能瓶颈，测试环境的redis是单机的。