个人愚见，如果你是从外部网络调用，会不会跟你的并发数本身有关？
举个例子，一次 http 请求处理耗时 200ms（外部网络请求等其它原因），每秒并发 50，理论数据 TPS 最大 250 左右。同样条件下，你将并发线程数开到每秒 100，服务器和执行机抗住的前提下，TPS 理论上能达到 500。可能跟你加不加 service mesh 没关系，TPS 大也是需要并发数达到一定程度才起得来。
只是个人推测，之前一次压测的时候遇到过类似估算问题。如果你是纯局域网或内网压测，可以忽略我上面说的

service mesh 本身是有网络开销。多用户跑设置集合点跑了吗？

在公司内网的环境下测试的，我们是以用户阶梯式增长的方式查看该请求的最大 TPS，达到峰值后我们还会再观察用户往上加是否还会增加 TPS(知道会造成延迟变大，但是 owner 更关心最大的承载量)。
本人初步判定情况如下：本身 service mesh 会对系统造成额外的资源开销，所以 service mesh 会对系统有优化效果这个想法暂时排除。在该系统架构中 service mesh 会替换掉原系统架构中的路由 route，可能 route 本身并发性能上就有点问题或者限制，在被替换成 service mesh 的方案后系统限制被解除，所以最大 TPS 会比之前不带 service mesh 的最大 TPS 更大。

就只有一个接口的请求，而且是查询的，响应时间都是几十毫秒级别的，设不设置集合点关系不大的。