You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/benchmark.md
+40-5Lines changed: 40 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,15 +12,15 @@ Compilation and linking options for the executable file: Compiled using gcc8, wi
12
12
13
13
## Test scenario
14
14
15
-
Throughput test: Test the QPS (Queries Per Second) of the service when the P999 latency of the caller is around 10ms.
15
+
Throughput test: Test the QPS (Queries Per Second) of the service when the P999 latency of the caller is around 10ms. Based on whether the called service continues to call downstream, it can be divided into pure server mode and proxy server mode. In the pure server mode, the call chain is: Client --> Server (target service), while in the proxy server mode, the call chain is: Client --> ProxyServer (target service) --> Server.
16
16
17
-
Long-tail request test: With a fixed QPS of 10,000 requests per second, simulate a scenario where 1% of the requests experience a 5ms long-tail latency (during the test, an additional stress testing tool is launched to send 1% of the long-tail request traffic), and examine the latency of ordinary requests (the latency of long-tail requests is not included in the results).
17
+
Long-tail request test: In pure server mode, with a fixed QPS of 10,000 requests per second, simulate a scenario where 1% of the requests experience a 5ms long-tail latency (during the test, an additional stress testing tool is launched to send 1% of the long-tail request traffic), and examine the latency of ordinary requests.
18
18
19
19
### About caller and callee
20
20
21
-
The callee is an echo service using the trpc protocol, and its RPC interface is:
21
+
The callee is an echo service using the trpc protocol. The RPC interface in pure server mode is:
// block current fiber, not block current fiber worker thread
47
+
::trpc::Status status = greeter_proxy_->SayHello(client_context, route_request, &route_reply);
48
+
49
+
reply->set_msg(route_reply.msg());
50
+
51
+
return status;
52
+
}
53
+
```
54
+
33
55
The main caller is a stress testing tool. During the test, it will establish 100 connections to the server, and the body size of each request is 10Byte.
It can be seen that the average latency of the merge mode is the lowest and the QPS is the highest. This is because the request processing in the merge mode does not cross threads and the cache miss is the smallest. So it can achieve a very low average latency and a high QPS.
66
+
It can be seen that in the merge mode, the average latency is lower and the QPS is higher. This is because the request processing in the merge mode does not cross threads and the cache miss is fewer, so it can achieve a very low average latency and a high QPS.
At around 10ms of P999 latency, the QPS of fiber mode and merge mode are comparable, but the fiber mode exhibits better performance in terms of tail latency compared to the merge mode. This is because in the fiber model, network IO and business processing logic can be parallelized across multiple cores, effectively utilizing multiple cores and achieving very low tail latency.
43
76
44
77
### Long-tail request test results
45
78
@@ -48,4 +81,6 @@ It can be seen that the average latency of the merge mode is the lowest and the
Note: the latency of long-tail requests is not included in the results.
85
+
51
86
It can be seen that the fiber mode is less affected by long-tail requests and has strong resistance to interference from long-tail requests, while the merge mode is greatly affected by long-tail latency. This is because in the fiber mode, requests can be processed in parallel by all worker threads, while in the merge mode, the processing of requests by worker threads cannot be parallelized across multiple cores. Once a certain request is processed for a long time, it will affect the processing time of the overall request.
0 commit comments