Ractor's speed is not light-speed

Talks

Satoshi "moris" Tagomori

6 talks

Ractor's speed is not light-speed

by Satoshi "moris" Tagomori

In the session titled "Ractor's Speed is Not Light-Speed," Satoshi Tagomori discusses Ractor, a new feature introduced in Ruby 3.0 that enables parallel execution of Ruby code across multiple CPU cores. The session highlights the experimental nature of Ractor and its potential in web applications while addressing its current limitations. Key points covered include:

Introduction to Ractor: Ractor is designed for parallelism, managing concurrency by dividing object spaces among multiple Ractors, reducing the complexities of multi-threading.
Managing Shareable Objects: Ractors work with shareable objects, which must be marked appropriately to be used across different Ractors, highlighting the differences between regular and isolated procs.
Performance Expectations: The performance of Ractor is anticipated to improve application speed by utilizing multiple CPU cores. However, its effectiveness compared to traditional process forking in web applications remains a key question.
Demonstration of 'Write Speed' Server: Tagomori introduces a simple Rack application server called "Write Speed" developed by himself. The server aims to process Rack applications with minimal overhead, although it currently faces challenges integrating with Sinatra and other frameworks due to unshareable objects.
Performance Benchmarks: Benchmarks showed promising results with a single connection but revealed issues like segmentation faults under load, indicating that Ractor is still in the experimental phase and has many unresolved problems.
Challenges with Compatibility: Many popular Ruby frameworks face compatibility issues with Ractor, particularly with accessing instance variables from non-main Ractors, leading to isolation errors.
Recommendations and Future Prospects: The talk encourages the community to work on developing Ractor-safe code, use immutable objects, and submit patches to Ruby core for improved performance and compatibility. Tagomori concludes by emphasizing the need for collaboration to enhance Ractor's integration into production environments.

00:00:03.199 Hello everyone. The title of this session is "Ractor's Speed is Not Light-Speed". This talk is about Ractor, a new feature of Ruby 3.0, and its application in web applications.

00:00:10.320 I am Satoshi Tagomori speaking. I am a freelance technical consultant since this summer, after leaving a company called Treasury Data.

00:00:12.000 I am also a hobby Ruby programmer and a member of the Sakai Ruby Meetup, which is a regional Ruby meetup near Sakai. Currently, it is an online meetup, and we welcome new people to the Sakai Ruby community. You can easily join us online.

00:01:06.560 Today, I will talk about Ractor, an experimental feature of Ruby 3.0 designed to run Ruby code in parallel on multiple CPU cores. This is a long-anticipated feature, and RubyKaigi has three sessions focused on Ractor. The first session, about parallel testing with Ractors, was held on Day 1 yesterday, and I am presenting this session. The other session, titled "Ruby React Quick," will take place on Day 3 tomorrow.

00:01:35.840 Ractor's feature allows the execution of Ruby code in parallel across multiple CPU cores by managing objects via Ractors. Each Ractor operates independently, enabling parallel runtime on several CPU cores. Managing state concurrency is essential, particularly in addressing multi-threading problems. Ractor divides the object space into multiple Ractor object spaces, meaning we do not have to worry about solving or managing multi-threading issues when using Ractor.

00:02:44.640 Additionally, we can move objects between Ractors. Once an object is moved, it becomes invisible from the original Ractor, which is part of the object management strategy. Ractors can share shareable objects, which include modules, classes, and application code. If marked as shareable, these definitions like constants and configurations need to be managed.

00:03:19.920 What does "shareable" mean? Shareable objects must be marked using the `make_shareable` method of the Ractor class. These objects will typically be frozen. However, a shareable proc is a special case. While the make_shareable method isolates proc objects, isolated procs are not frozen. If you call binding methods on an isolated proc, it raises an ArgumentError, and all referred values from the proc must also be shareable.

00:04:34.880 For example, if we have a usual proc on the left side of the comparison, and we assign a value of 1 to x, invoking p1 will return x + 2. After assigning 5 to x, p1 will return 7 since x has been updated due to its reference. However, for an isolated proc, when we assign 1 and mark it as shareable, the context does not change even when x is updated. Hence, the value returned by p2 will still be 3, as it remains unaltered in context.

00:05:31.280 Moreover, isolated procs cannot refer to unshareable objects, as illustrated in the first example. If s1 is a mutable string, it cannot be a shareable object. Attempting to call make_shareable on it will raise an isolation error. However, if s2 is a frozen string, then p4 can be marked as a shareable isolated proc.

00:06:41.440 The main point about Ractor revolves around speed because Ractor is designed to run Ruby code in parallel across multiple CPU cores. We expect a performance enhancement that can be several times faster if the last operation uses n CPU cores.

00:07:12.960 The key question is whether this holds true for web applications, and if it truly makes web applications faster than processes created via fork. Is my web application running faster with Ractor than with the current deployment? Speed is crucial, so we need an experimental application server that utilizes Ractor.

00:08:02.640 This server should be a Rack application server that supports Rack application protocols between the server and applications. It needs to handle processing workers, accept established connections, read requests, run Ruby Rack applications, and write responses, all while maintaining speed and optimal performance with minimal overhead.

00:08:43.760 I apologize for my poor English pronunciation. This server, called "Write Speed," is an application server that I developed myself. Currently, it has limited features as a Rack application server, but we can start running Rack applications on it.

00:09:19.600 Now let me show you a demonstration of Write Speed. This is a very simple Rack application that will respond with a status 200 and a string "OK" to any request. Let's execute our web request server with this application. I will also run this application using Write Speed.

00:10:24.960 It started running with eight workers. The server is experimental, and it's listening on all ports. Sending a request to that endpoint returns a good response. We also have a Rack server, so we can learn and run Sinatra applications. However, I couldn't resolve all issues relating to Sinatra due to many unshareable objects and settings that involve configurations, which leads to complications.

00:11:06.640 Although I have patched some elements, right now Sinatra applications cannot run on Write Speed. I have a layered application that is too massive and involves many instances of unshareable objects, making it unsuitable for Write Speed. We need many patches on Sinatra and other Ruby frameworks to ensure compatibility with Ractor.

00:12:08.800 The significant challenge is ensuring that our applications can integrate with Ractor without issues. I'd like to demonstrate the benchmark in terms of traffic, as speed is crucial. When executing a benchmark tool using Write Speed with a single connection and thread, the server processed 5000 requests per second, which is impressive.

00:13:02.560 Next, I will run a similar traffic test using multiple connections and threads to gauge performance under load. However, unexpectedly, a segmentation fault caused by the Ruby runtime occurred, indicating that Ractor is still in the experimental phase and that there are issues yet to be resolved.

00:14:01.600 There are numerous issues with running web applications on Ractor that need resolution, and I hope the crash I experienced will be fixed soon. I will investigate the root cause after this session. One issue arises from accessing module or class instance variables from non-main Ractors, which causes isolation errors.

00:14:32.960 Many frameworks like Sinatra and Rails rely heavily on these instance variables, which makes it a significant limitation in terms of Ractor compatibility. Therefore, it's advisable to avoid using these patterns in production-level code until a definitive solution emerges.

00:15:16.640 Furthermore, directly using defaults tied to instance variable behavior is problematic in Ractors. For instance, methods such as JSON.dump cannot be used in non-main Ractors currently. These challenges need to be addressed, and while there are no fixes yet, there are plans to allow for the access of module or class instance variables in the future.

00:17:00.800 Moreover, accessing unfrozen or unshareable constants raises exceptions. Shareable constants can be accessed but must still conform to the rules around shareability. Values marked as mutable or containing references to unshareable objects can lead to breakdowns.

00:17:19.920 My recommendation is to use frozen strings and to ensure your string literals are immutable. Using new forms of magic comments to define arrays and hashes can help streamline development while maintaining compatibility with Ractor. Overall, let's develop Ractor-safe code while improving performance.

00:18:02.800 To summarize, there are many opportunities for development within Ruby core and major libraries, which could lead to improved performance in Ruby's web applications. Contributions are welcome, and we have spaces for patches across all frameworks.

00:18:54.240 In conclusion, we must focus on writing patches for Ruby core and enhancing Ractor's compatibility with frameworks and libraries to make it production-ready in the future. Thank you very much for your attention.

RubyKaigi 2021 Takeout