brpc
brpc copied to clipboard
apache
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...
### What problem does this PR solve? Issue Number: Problem Summary: ### What is changed and the side effects? Changed: 1. 支持半关闭：无需SetFailed，关闭写入端，但不影响读数据。 2. 支持在数据写入socket写入成功后调用id_wait回调函数：对于一些请求和响应不是一一对应的场景，例如WebSocket、TCP Stream客户端、Streaming rpc等，只需要关注数据是否写入成功。数据写入socket写入成功后调用id_wait回调函数，可以统计成功率、耗时等。#2545 Side effects: - Performance...
**Describe the bug (描述bug)** [Set-Cookie - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) > To send multiple cookies, multiple Set-Cookie headers should be sent in the same response. **To Reproduce (复现方法)** 使用example/http_c++，server调用多次set-cookie，client只能收到一个set-cookie **Expected behavior...
### What problem does this PR solve? Issue Number: Problem Summary: 此前遇到过IOBuf泄漏的情况，从heap profiler看到泄漏的位置是Socket读包的位置，实际上是因为IOBuf的tls缓存复用机制，掩盖了业务代码中存在IOBuf泄漏的问题。 ### What is changed and the side effects? Changed: 受Contention Profiler启发，开发一个IOBuf Profiler，将未释放的IOBuf::Block的引用计数操作的调用栈及其操作数量（整数表示持有引用计数，负数表示释放引用计数）展示位调用图。通过可视化的方式，可快速定位到一些可能存在泄漏的模块，缩小排查的范围。 因为数据上报有一定的顺序要求，所以没有使用Contention Profiler的方案（Collector）来上报数据，而是使用 #2492 封装的无锁队列来上报。 该工具可以扩展到其他引用计数相关的数据结构。...
### What problem does this PR solve? Issue Number: resolve #2285 Problem Summary: ### What is changed and the side effects? Changed: Side effects: - Performance effects(性能影响): - Breaking backward...
Describe the bug (描述bug) 使用 clang-17 进行autofdo优化。 服务出现 F0314 16:33:23.030470 211226 socket.cpp:1071, IsWriteComplete] Check failed: p != NULL *** Check failure stack trace: *** F0314 16:33:23.035867 211251 socket.cpp:1036, IsWriteComplete] Check...
在cpuwide_time_ns函数中使用tsc计算时间时，使用的频率不匹配，具体描述如下： 在cpuwide_time_ns函数中有两种计算时间的方式： （1）调用clock_gettime（即函数monotonic_time_ns）来获取时间 （2）使用 tsc/cpu_freq 来计算时间，存在以下两个疑问： a. cpu_freq是从函数read_cpu_frequency中获取的，在该函数中从/proc/cpuinfo中读取了CPU的频率，虽然在代码中通过constant_tsc和nonstop_tsc的保证了tsc的恒定频率，但是通过查阅网上资料发现tsc的频率与cpu频率无直接关系，所以这里使用的频率并不准确。 b. read_cpu_frequency函数中只读取了/proc/cpuinfo中第一个"cpu MHz"，在多处理器上(即使是constant_tsc和nonstop_tsc都存在的情况下)， cpu MHz的频率也可能是存在差异的，以下是x86 debian-12环境下多处理器的cpu MHz值，可以看到processor 0和1的cpu MHz 约为3800,但是processor 9的值为2900。 rdtsc指令获取的是当前处理器的时间戳计数器的值，当前使用的处理器也不一定就是processor 0 ``` root@amd64-14:/home/data# uname -a Linux amd64-14 6.1.0-12-amd64 #1 SMP...
### What problem does this PR solve? Issue Number: Problem Summary: ### What is changed and the side effects? Changed: Side effects: - Performance effects(性能影响): - Breaking backward compatibility(向后兼容性): ---...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** Block size 现在是一个常量，如果支持动态修改的话会出现什么问题吗？使用场景是在我们的rpc里有一些是大块的5mb数据最好需要连续地址，其他rpc则是很小的。不应该公用一个blocksize。 **Describe the solution you'd like (描述你期望的解决方法)** 支持iobuf初始化提供一个自定义blocksize，如果可以的话我会提一个pr **Describe alternatives you've considered (描述你想到的折衷方案)** **Additional context/screenshots (更多上下文/截图)**
brpc目前从socket读取到的数据是放在IOBuf中的，但是由于IOBuf是一个非连续的内存缓冲区，如果用户需要保证接收到的是一块连续的内存的话需要进行一次内存拷贝，但是在大数据量的场景下内存拷贝存在性能瓶颈，请问有什么方法可以避免这次内存拷贝呢
**Describe the bug (描述bug)** adx服务在启动的时候大概率会出现卡死。vars接口显示创建了大量bthread和channel_connections，并且不断增长，最后导致OOM。如果能成功启动，服务运行还是比较稳定，高峰时bthread最多1800个，channel_connections最多2500个。 brpc服务接收到请求后会广播给下游dsp。协议基本都是http。我们对每一个dsp请求都会启一个bthread，bthread里同步请求下游服务，设定的超时时间为500ms左右。处理服务请求的bthread会join每个dsp的bthread。 服务最高并发不到100。dsp120个左右。 gdb调试的时候，worker线程堆栈目前看到有两种： 1. worker都在发送dsp请求，暂停在dsp的CallMethod。看堆栈貌似把pthread卡住了  2. worker都在建立ssl链接  有没有排查思路？ **To Reproduce (复现方法)** **Expected behavior (期望行为)** **Versions (各种版本)** OS: ubuntu 22.04.3 Compiler: g++ 11.4 brpc:...
