Performance with --count 1, or IPC

[danhealy]

First off - thank you for this awesome project! The examples are also particularly helpful. In some cases, though, I think I could really benefit from a broader discussion of context.

From this example:
https://github.com/socketry/async-websocket/blob/main/examples/mud/config.ru

It seems that the choice was made intentionally to use --count 1 and to establish the Room @users shared memory.

I assume that a progression of this example for a single host context could be to remove the --count 1 constraint in favor of IPC - like IO::Endpoint.unix("room.ipc") ?

I'm curious if that direction seems correct & what the performance impact of each choice might be? In the broader async ecosystem, particularly falcon, is there a best practice for this already?

[ioquatix]

Yes, that's correct, the decision to use --count 1 is to allow the example to focus on WebSockets rather than IPC.

There are many options for IPC - depending on your requirements for persistence etc.

I think we tend to underestimate the raw performance of modern computers, so I think the impact of IPC is minimal in practice compared to application code. For example, using async-redis as a shared message bus is totally fine.

As an alternative consideration, you could also start an instance of falcon per "game instance" and connect a limited number of players, or use an instance of falcon per area of the game, etc. There are different ways to shard with different trade offs, but per-game instances is a valid approach that keeps code simple.

[danhealy]

Thanks for the response! I guess these questions are really more for falcon.

I'm not sure when or if --count 1 might be the cause of a performance bottleneck. However, I agree that async-redis would be the most robust option for multi-process or multi-host IPC, when the need arises. In terms of code complexity, introducing async-redis is about the same as a unix IPC solution, I also assume the performance would also be about the same on single-host. Deployment would be a little more complex, which is the reason I was thinking of unix IPC as a middle ground.

[ioquatix]

There are three main issues to consider w.r.t. only having one process (and/or thread).

1. Performance: In essence, Ruby is single threaded, and two distinct processes will always beat a single process with multiple ractors/threads/fibers when dealing with true parallelism.

2. Isolation: In failure scenarios, the more work a single process is doing, the less isolated and bigger the blast radius will be. Using --count 1 means that a single critical failure (e.g. out of memory, VM bug, etc) can take down your entire server.

3. Security: Shared mutable state may lead to security issues. While a single request at a time server (or single session per process) model may avoid some issues, a server that handles more requests at a time is inherently likely to encounter such issues.

Regarding deployment, of course more systems = more complexity, however it's also true that having a shared repository for mutable state (e.g. redis) will allow you to make your web application server (e.g. falcon) idempotent, which simplifies handling restarts and/or deploys. If you put state in your web application processes, handling restarts and failures gets more tricky.

I hope that helps clarify things.