【 使用环境 】测试环境
【 OB or 其他组件 】observer-ce-4.5,obproxy-4.3.6
【 使用版本 】
【问题描述】三个主机，9节点集群，使用obd部署，连接obproxy执行建表，需要30秒，但是drop table 很快。
将proxy上的rpc_client_net_read_timeout从默认的30s改为5s后，建表操作在毫秒级返回。
常规理解，这个参数表达的意思是socket recv操作时指定的最大超时时间，而不是每次操作都需要这么多超时时间，感觉是存在bug。但是改为5秒后，照理也应该等5秒返回，实际确实毫秒级返回，不好理解。
【复现路径】
sql : create table speedtest (id int)；
【附件及日志】无
日志也得附上吧
提供一下操作截图看看
学习来了
obproxy.log (781.8 KB)
show_trace.txt (9.8 KB)
看上去重路由导致的，应该怎么调整？
rpc_client_net_read_timeout由30秒调为5秒，也会出现慢的情况。
学习一下大家的经验
如果有已经解决的帖子，给个链接？
便于触发读超时，可以调小配置项超时时间 你这个调小的目的 是什么呢？
纯粹是猜测原因，对于创建表慢的原因查不出来，排查试试。改小以后，还真正常了一会
发现日志中一个问题，所有的observer都是follower，正常吗？
解决了不
感谢解答client问题！对于net场景，我的经验是重点关注read配置。
没解决。
了解情况
建表跟这个参数也有关系？
排查原因。因为在参数里面等于30秒的不多，看上去这个比较像，所以就试试。后面发现也不行
你从哪里看到的重新路由了 你不用obproxy直连observer操作慢么？
server_process_request_time_us=30133693, server_response_read_time_us=0, plugin_decompress_response_time_us=0, server_response_analyze_time_us=2, ok_packet_trim_time_us=63, client_response_write_time_us=63, request_total_time_us=30134399
从日志的信息 来看主要是目标server该执行SQL的耗时
直接用客户端建表，300多张表，建了靠2个小时，不知道咋解决
