Also, looking at those numbers, event machine was using more than 3x the processor time:

> (17.97+8.42) / 241.45
=> 0.10929799130254712

> (76.58+5.03) / 243.25
=> 0.3354984583761562

So even if, for example, it was 5% better in wall clock time (unproven), it's costing you ~3x in processor time.

Realistically as long as the network is the same for both tests, it's not going to change the outcome, however it might affect the ratio of processor/network which could influence some of the numbers. I tried 10 x 100_000:

I changed the code to do 10 x 10,000 which is 100k. Better to benchmark with a fixed known load.

This is a good talk which will help give you a deeper understanding of how to compare these types of systems: www.youtube.com/watch?v=r-TL...

IOW, since eventmachine and async follow largely the same design strategy (event loop), I'd expect them to be similar in terms of performance.

One thing to confirm would be the use of per-message deflate and how it's negotiated. Since each message may need to be processed by libz/deflate, it could change the performance characteristics. This wouldn't be a comparison of async vs eventmachine, but different connection parameters.

One thing you'll notice is that while the wall clock run-time was about the same (25s) the actual user processor time was greatly reduced, in conclusion, one could say that async was more efficient (less time spent executing CPU instructions). I'm not sure what would specifically cause this though.

This benchmark is hard to draw conclusions from. The network conditions are constantly changing. I got similar results from both systems but I also saw fluctuations one way or another too. To really see the difference, you'd need to run a local "firehose" to remove the network variance.

Hello

For example, when I switched @tinyzap.com from Puma to @ioquatix.bsky.social's Falcon server, my entire web application was much more responsive and loads faster in the browser because each image you see in the screenshot below fires a request to Rails to get the image URL.

The Ruby Fiber::Scheduler embraces the GVL while Threads constantly bump up against it. I specifically designed the scheduler to work with the GVL with minimal impact. However, that being said, in the future I want to remove the GVL and experiment with a work stealing multi-threaded scheduler.

You should write an adapter for bake.

I’m having a sugar collapse. Will go swimming to burn off the excess energy.

I will miss your newsletter, wishing you a speedy recovery!