brpc
brpc copied to clipboard
brpc is an Industrial-grade RPC framework using C++ Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. "brpc" means...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** Currently, aliyun periodically do http health check for the service run by brpc. The health check send rst package instead of...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** 当server端宕机重启恢复后, client端要花较长时间才能成功连上server端。 同以下issue #1057 原因是tcp重传的backoff机制会导致重传时间越来越长。 例如最终120秒才重传一次, 但可能server端第10秒的时候已经恢复, 导致server端恢复110秒后, client端才请求成功 **Describe the solution you'd like (描述你期望的解决方法)** 支持tcp_user_timeout, 提早断开连接。 目前[grpc已经支持](https://groups.google.com/forum/#!topic/grpc-io/6VZYCFZpyTI) **Describe alternatives you've...
Compress method Compress size(B) Compress time(us) Decompress time(us) Compress throughput(MB/s) Decompress throughput(MB/s) Compress ratio Snappy 128 0.630420 0.676840 193.633312 180.353278 37.500000% Gzip 128 4.886340 0.804860 24.981952 151.666517 47.656250% Zlib 128...
**Describe the bug (描述bug)** 最新版brpc,使用 OnReadOnePart 接口请求server,server端流式返回数据,回传数据中 server 挂掉,未调用OnEndOfMessage,接口阻塞 **Expected behavior (期望行为)** 期望在server挂掉时,可以捕获异常,正常结束本次 ProgressiveReader 调用
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** 线上C++应用基于brpc开发,使用的是jemalloc(不是tcmalloc);在发生内存泄露的时候,希望有工具辅助排查内存泄露点 **Describe the solution you'd like (描述你期望的解决方法)** brpc支持jemalloc下的内存profiling;支持线上开启,使用 **Describe alternatives you've considered (描述你想到的折衷方案)** **Additional context/screenshots (更多上下文/截图)**
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** bthread这种模型更适合网络IO比较重的场景,对于某些场景比如磁盘IO比较重的话,会导致bthread worker线程TaskGroup长期被占用,导致别的任务得不到调度。 **Describe the solution you'd like (描述你期望的解决方法)** bthread支持多个线程池,比如线程池1处理brpc/braft消息的分发,线程池2用于用户业务内部代码的运转。这样也方便做隔离,防止因为业务内部代码占用比较多的时间片资源从而导致别的任务得不到调度,进一步也实现了按优先级调度的策略。 **Describe alternatives you've considered (描述你想到的折衷方案)** 有一种折中的方式是自己搞一个线程池,bthread只用于brpc/braft等协议的交互,对于内部比如要写盘这些重IO操作的,可以丢到自己的线程池中去实现。但这里也有个性能问题就是会涉及到多次bthreadpthread的来回切换,而且遇到锁的处理mutex/bmutex必须非常小心,否则特别容易出现死锁的问题。 **Additional context/screenshots (更多上下文/截图)**
在brpc服务中调用openmp进行矩阵运算,在设置了环境变量`OMP_NUM_THREADS和OMP_DYNAMIC="FALSE"`后,cpu消耗依旧不受控制。 例:`OMP_NUM_THREADS=4 OMP_DYNAMIC="FALSE"`;单个client请求的情况下,cpu消耗达到在600%-1000%之间波动;多个client并发的情况下,cpu消耗更加不可控。 已验证使用pthread对上述openmp的计算模块进行多线程调用时cpu消耗正常;已验证在brpc服务中去除openmp的相关模块后正常。 请问上述情况和bthread有没有关系?或者有什么排查方向吗?非常感谢!
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** lalb在SelectServer的循环中,如果选到不可用的节点,在一定条件下会继续尝试节点树的右子树: [判断是否可以进入右子树](https://github.com/apache/brpc/blob/master/src/brpc/policy/locality_aware_load_balancer.cpp#L334) 例如某一时刻节点树只有两个节点,0号不可用1号可用。 按照现在的逻辑如果第一次选中了0,那么这次选择会失败,因为0没有可用的右子树,但是节点树里确实有可用的1号节点。如果连续两次(n=2)一开始选到0,那这一次lb会失败。 在有节点探活失败的情况下可能发生,虽然概率不大,但运气不好每次都选中不可用节点的概率确实存在,尤其是在下游节点不多的情况下。 **Describe the solution you'd like (描述你期望的解决方法)** 在单次Select循环中,如果节点不可用即[判断是否可以进入右子树](https://github.com/apache/brpc/blob/master/src/brpc/policy/locality_aware_load_balancer.cpp#L334)为false, 那么尝试进入左子树作为兜底,例如: `else { dice = butil::fast_rand_less_than(left); index = index...
 合并为 ` b = _bottom.load(butil::memory_order_seq_cst);` 不知道这里为什么要加两个fence
**Describe the bug (描述bug)** 自定义数据类型type A, A 中包含 unordered_map a; 使用: Adder add; Window win; 然后, win初始化为60s: add