Is Ractor ready for production use?

[xuchaoqian]

We are currently using Actix, but it has weak support for async/await, and it is no longer actively maintained.

Recently, we came across Ractor, and it looks great. Now we have two questions:

1. Is Ractor(excluding Ractor Cluster) ready for production use?
2. How does its performance compare to Actix?

[slawlor]

For 1. It is production ready and is being used so.

For 2. I haven't specifically benchmarked it against actix, however we do have a benchmark suite in ractor which should be pretty easily replicated for actix I would hope

[slawlor]

I would just reiterate to your own point, I wouldn't consider ractor_cluster production ready as it hasn't been stress tested in the same way but it should be pretty functional to many problems

[xuchaoqian]

@slawlor Thank you for your response. We'll test it and give feedback here.

[xuchaoqian]

@slawlor

The following are the comparison results. If there are any errors, please let me know them. It is surprising that Ractor performs very slow when invoking call in a multi-threaded context, around 10 times slower compared to a single-threaded context.

see repo: actix-ractor-benches

actix-ractor-benches

Preconditions

• CPU: 3.1 GHz Quad-Core Intel Core i7
• Memory: 16 GB 2133 MHz LPDDR3
• MacOS: 13.6.5
• Rust: 1.77
• Actix: 0.13.3
• Ractor: 0.9.7

cargo bench --bench actix

• Creation of 100 actors time: 57.613 µs
• Creation of 10000 actors time: 10.864 ms
• Waiting on 100000 messages to be processed [ by single-threaded + do_send ] time: 14.491 ms
• Waiting on 100000 messages to be processed [ by multi-threaded + do_send ] time: 9.1211 ms
• Waiting on 100000 messages to be processed [ by single-threaded + send ] time: 241.23 ms
• Waiting on 100000 messages to be processed [ by multi-threaded + send ] time: 987.28 ms

cargo bench --bench ractor

• Creation of 100 actors time: 772.38 µs
• Creation of 10000 actors time: 81.368 ms
• Waiting on 100000 messages to be processed [ by single-threaded + cast ] time: 40.488 ms
• Waiting on 100000 messages to be processed [ by multi-threaded + cast ] time: 38.376 ms
• Waiting on 100000 messages to be processed [ by single-threaded + call ] time: 127.87 ms
• Waiting on 100000 messages to be processed [ by multi-threaded + call ] time: 1.2065 s

Conclusion

• In terms of creating actors, Actix is 5~15x faster than Ractor.
• Actix's do_send is 3~5x faster than Ractor's cast in single-threaded context.
• Actix's do_send is 3~5x faster than Ractor's cast in multi-threaded context.
• Actix's send is 1.5~2x slower than Ractor's call in single-threaded context.🚀🚀🚀
• Actix's send is 1.2~1.5x faster than Ractor's call in multi-threaded context.

[slawlor]

OK this is all helpful information. I think this is likely going to heavily boil down to runtime choices, and while ractor is slower in many contexts from actix's actors, there's a lot of other benefits from being true-to-form for async rust patterns (This reddit post outlines a lot of reasons actix is actively discouraged by a lot of people and why it doesn't jive well with async/await Rust).

ractor is imho production ready, since it's actively maintained and used in multiple production environments today that I'm aware of. As for performance, that's going to be up to a few things.

1. It's a known performance hit that we move messages to dyn Any in the main actor messaging channel, but it gains a lot of power in the usage of ActorCell and the centralized way of bundling actors of differing types together. This is something I'm trying to identify a way around or move away from, but today is a per-message perf hit.
2. Using boxed futures with async-trait. All actor handlers use boxed futures via the async-trait proc macro magic. This is something we already have a solution for with the stabilization of async fn's in traits by Rust. See Support async fn in traits. #206 FMI.
3. Tokio vs actix runtime. This one we can't do anything about, as actix using synchronous handlers, vs tokio using true async/await Rust but having it's own scheduler which isn't specifically tuned for message passing and handling. This is work that is outside the scope of this crate imo.