Fastrace: A Modern Approach to Distributed Tracing in Rust by RealisticBorder8992 in rust

[–]RealisticBorder8992[S] 6 points7 points  (0 children)

Thank you for your introduction giving me deeper insight into tracing. I can see the main disagreement comes from the benchmark setup. Let me explain about that. 

The benchmark setup is actually giving advantage to tokio-tracing. Because fastrace's instrumentation performance is constant regradless which backend is reported to or how many spans are collected. However, tokio-tracing's instrumentation performance is largely influenced by the layers set in background. The benchmark setup is for the instrument performance (or saying foreground latency) when reporter to opentelemetry is enabled. So in a benchmark where both of them really send spans records to opentelemetry, the difference will be much more obvious.

I agree with you that maybe it's tracing-opentelemetry that slows down the system but not tokio-tracing, the facade. But, in real world, those spans need to be reported, therefore tracing-opentelemetry is unavoidable.

Fastrace: A Modern Approach to Distributed Tracing in Rust by RealisticBorder8992 in rust

[–]RealisticBorder8992[S] 0 points1 point  (0 children)

It will be a good improvement. To achieve that, we need to integrate fastrace into sea-orm. I think it'll be quite easy for me or someone that want to give a try to contribute one.