【 使用环境 】测试环境
【 OB or 其他组件 】OBServer和OBProxy
【 使用版本 】4.2.x
【问题描述】所有的leader都在其中一个OBServer上。 在低并发下，经obproxy中转对比直连OBServer，整体吞吐量要低些。但是在高并发下，有点倒过来了，这个符合预期吗？ 是obproxy在这块有些优化吗？还是说有测试误差造成的？
【复现路径】sysbench write only场景，测试4、8、16、32、64、128并发下
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
日志采集场景: 集群基础信息
日志采集命令: obdiag gather scene run --scene=observer.base
为了更好地理解并解决您遇到的问题，我们需要一些额外的信息来进行更准确的分析：
根据您的描述，这种现象可能与 obproxy 的工作模式有关。obproxy 作为代理服务器，在低并发时可能会引入额外的开销，而在高并发时，它能够发挥其负载均衡和连接池的优势，从而提高整体性能。不过，这还需要通过具体的数据和配置来进一步验证。建议您使用上述命令收集集群的基础信息，并将结果提供给我们以便进行更深入的分析。
附上敏捷诊断工具 obdiag 使用帮助链接
只有在单节点 OB 情况下，才可以省去 obproxy 而让应用直连 observer ，生产环境基本不这么用，因为没有高可用，也不打算扩展 OB 。
标准的使用方式是 obproxy + observer ，obproxy 只是起一个 路由功能（会话路由、sql路由、事务路由等），不做计算。observer 才是读写数据的。observer sql 引擎虽然也有路由能力，那个代价比 obproxy 路由要高很多，这个不需要实验验证，设计就是这样的。
所以，当 observer 有多个节点的时候（不管是单副本还是多副本），obproxy 都是必须的。
生产环境为了 obproxy 的高可用，一般会部署多个obproxy（跟observer 同机部署或者独立部署都可以），然后再借助一个 负载均衡产品做一个 vip 为 多个 obproxy 提供路由服务（目的是高可用、其次是负载均衡）。
学习了
正常生产环境还是连接odp比较好,如果连接OBSERVER的话,还需要自己确定分区路由吧
