Why Tonic not good in beckmark of multi core?

1

comparing grpc performance

above link is compare grpc framework.

Rust-Tonic is Best in single-core
but for multi core have more latency and not good increase throughout. and is not best,

where is problem in multicore ??

in some article i saw said about tokio performance issue for
multi-core.

2

The answer is mostly the same as for your other post.

That said, Tonic actually has a pretty good performance in their two-core benchmark, even if it's not at the top. Beyond that, I see two things you could change in their implementation that would increase it's performance on the benchmark, though one of them might not be an improvement on real-world workloads (it depends on the application).

3

Thanks. That post was about compare tonic vs golang

But here is about performance degrade in multi core !!

This is not correct answer,

I want know why degrade ??

Where is bottleneck ??

Why Akka with GC must be
faster than Rust !!

Then exist a issue
Or not very optimized !!

4

It seems like performance is important to you and you are upset because there are other libraries in other languages which are faster than Tonic.

If so, I would suggest looking at alternative GRPC libraries (the article you linked in your other post mentioned grpc-rs) or run a Tonic server through a profiler so you can answer questions about performance yourself. You might even be able to contribute a pull request back to Tonic to help speed things up for everyone!

I understand you might be feeling frustrated but yelling at people in this forum won't get you anywhere.

3 Likes
5

Nooo, we love Tonic and we use it for whole backend and that serving to 430K
Client ...

We have another team and we interested in help to rust community to improve ecosystem

I asked exist issue ?!

but no one person exist to accept this, just your are.

We are ready to help to rust Tonic .

Our team migrated from Akka / Elixir to Rust-Tokio

This is our roadmap ...

6

I'm going to assume that the way you came across initially is a language barrier problem, and I will try to answer more directly.

In general, Tonic is able to run independently on several threads without there being any extra performance cost compared to single-threaded.

One of the things that's hurting Rust's performance in that particular benchmark is that the accept loop is running directly inside a call to block_on. This can be a performance problem because a tokio::spawn task will never run on the same thread as a block_on task, which means that all connections must be transferred to another Tokio thread before they can be processed.

Moving the accept loop into a spawned task can help because then it is possible for tasks to be executed without having to move them to another thread.

3 Likes
7

Thanks for good description.

But when define tokio with macro #[tokio::main]
This dont it follow your second part of answer ??

My mean is we must always create runtime
Manually to do this or macro style do this ?!

8

The #[tokio::main] compiles down to code using block_on. For example, this:

#[tokio::main]
async fn main() {
    println!("Hello world");
}

becomes this:

fn main() {
    tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            println!("Hello world");
        })
}
9

thanks for take your time.

then from now we always run server loop inside a spawned task. :clap:

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.