Unexpected perf measurements (TCP) about seastar

[avikivity]

To get valid performance measurements you have to simulate the workload your application is doing.

Seastar is oriented towards complex applications that require concurrent operations, and provides good support for that. For example. a ScyllaDB query is converted to two or more RPC requests to local and remote nodes, which in turn can be converted to several parallel reads from disk files.

For simple recv-transform-send, Seastar will be less efficient than libuv style callbacks.

[avikivity]

No one (I expect) will be able to invest the hours needed to even understand what your are measuring, let alone figure out the answer.

You have to distill the question to something more familiar to others and simpler to understand.

[volodyaleo]

I attached the "http2 emulation" code.

The test tcp_10k_batch_1 performs only 1 request each time:

• Request
• Response (always wait response before next request)
• Request
• Response

The test tcp_10k_batch_10 performs 10 parallel requests:

• Request
• Request
• Request
• Request
• Response
• Response
• Response
• Response
• Request
• Response
• ... 10 parallel requests ...

The test log shows an abnormal result (it is faster to wait for a response before sending the next request than to send each request without waiting):

rpc_bench.tcp_10k_batch_1                      75000    14.005us    59.653ns    13.523us    14.065us      17.003       9.018         0.0
rpc_bench.tcp_10k_batch_10                     65000    16.501us   125.496ns    16.344us    16.714us       7.932       3.185         0.0

[volodyaleo]

I tried to get the "time to perform request" using the seastar performance testing framework.

[avikivity]

I'm not going to read and understand the "http2 emulation" code. You'll have to narrow it down to something simple.

[volodyaleo]

It turns out that working in a synchronous way (send-wait-receive in loop) via single connection is faster than working asynchronously (multiple sends and co-awaits) via multiple independent connections.

[avikivity]

That's not unexpected if the round-trip latency is very low.

[volodyaleo]

Thanks, I got it. If the round-trip latency is very low, the efencity may drop down (depends on task ordering).

So, to get valid performance measurements I need to take a look only on "send-wait-receive" loop.

Is it correct?

[volodyaleo]

Thanks