apache / apache/brpc

brpc单个请求延时较高

Open
#2,000 25 comments 0 reactions 0 assignees View on GitHub
performance
Dominant language
C++
Stars
17.6k
Forks
4.1k
Avg merge
2d 12h
Merged PRs (30d)
69

Description

**Describe the bug (描述bug)**
使用redis-benchmark -t set -c 1 -n 100000单链接无压力测试,对比redis server的20+us的单个请求延时,brpc redis server一般达到了40us+

**To Reproduce (复现方法)**
redis-benchmark -t set -c 1 -n 100000

**Expected behavior (期望行为)**
较低的延时。

**Versions (各种版本)**
OS:
Compiler:
brpc:
protobuf:

**Additional context/screenshots (更多上下文/截图)**
int Socket::StartInputEvent(SocketId id, uint32_t events,
const bthread_attr_t& thread_attr) {
SocketUniquePtr s;
if (Address(id, &s) < 0) {
return -1;
}
if (NULL == s->_on_edge_triggered_events) {
// Callback can be NULL when receiving error epoll events
// (Added into epoll by `WaitConnected')
return 0;
}
if (s->fd() < 0) {
#if defined(OS_LINUX)
CHECK(!(events & EPOLLIN)) << "epoll_events=" << events;
#elif defined(OS_MACOSX)
CHECK((short)events != EVFILT_READ) << "kqueue filter=" << events;
#endif
return -1;
}

// if (events & has_epollrdhup) {
// s->_eof = 1;
// }
// Passing e[i].events causes complex visibil2ity issues and
// requires stronger memory fences, since reading the fd returns
// error as well, we don't pass the events.
if (s->_nevent.fetch_add(1, butil::memory_order_acq_rel) == 0) {
// According to the stats, above fetch_add is very effective. In a
// server processing 1 million requests per second, this counter
// is just 1500~1700/s
g_vars->neventthread << 1;

bthread_t tid;
// transfer ownership as well, don't use s anymore!
Socket* const p = s.release();

bthread_attr_t attr = thread_attr;
attr.keytable_pool = p->_keytable_pool;
//如果此处注释了if, 不使用bthread 执行task,而是直接执行,则延时直接下降到20us
if (bthread_start_urgent(&tid, &attr, ProcessEvent, p) != 0) {
LOG(FATAL) << "Fail to start ProcessEvent";
ProcessEvent(p);
}
}
return 0;
}

Contributor guide

Open the contributing guide

Research direction

Start at Socket::StartInputEvent and the ProcessEvent entry point shown in the report. Reproduce the comparison with redis-benchmark -t set -c 1 -n 100000, then measure the latency difference between the bthread path and direct processing. Done means the single-request latency is reduced and the relevant benchmark behavior is verified.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, redis
Domain
backend-api-design, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.