Readme Improvment regarding concurrent requests

[feliperaul]

"But will it scale?" is an important concern for everyone that considers this gem, since ActionCable itself is pretty bad (unfortunately) when we hit thousands of subscribers (as AnyCable benchmarks shows).

Right at the beginning of the readme it states that "MessageBus can handle thousands of concurrent long polls on all popular Ruby webservers", but I wish to improve it with some numbers so we can have a ballpark idea of how many concurrent connections it could actually handle.

And honestly I'm ignorant on how exactly that can be done! If it uses (by default) a long-polling stategy with streaming which keeps "the connection open for the configured long-polling interval (25 seconds by default)" (I'm quoting from the README), doesn't it mean that for every subscriber there will be an open connection that remains open all the time?

If you have a Puma server with 5 threads and 2 workers, can't it only handle 10 concurrent requests? By "the connections remain open during the long poll intervall" I assumed that thread would not be available for responding to any other requests (like, for instance, if it was a regular rails request that took very long to respond - the thread is stuck until that request finishes).

I commit myself to make a pull request to improve the readme on this part, but of course I need to understand how this works first :)

(I read the how it works section, but couldn't find these answers there).

[SamSaffron]

If you have a Puma server with 5 threads and 2 workers, can't it only handle 10 concurrent requests?

Sort of, if puma is in charge, but with message bus puma is no longer in charge.

Puma/Unicorn/Passenger all implement rack hijack which is pretty much still implemented per: https://old.blog.phusion.nl/2013/01/23/the-new-rack-socket-hijacking-api/

So we are not beholden to the 1 connection per process unicorn has and so on.

[cheynewallace]

I would really like to see some more info on this too.

I have just spent hours looking into using this gem, but am now realising that it's probably not going to work. I have a single server, 4 puma processes running 4 threads each. The API comfortably serves a few thousand users which only speak to it every now and then. I dont want to scale up more servers just for this little feature id like to add.

I wanted to use message bus to occasionally send messages to these hosts but if it seems like iv mis understood that this will be tieing up connections for each long poll.

Is that true? given my 4 puma process, 4 thread config, does that mean my concurrency is something like 64?

[SamSaffron]

I wanted to use message bus to occasionally send messages to these hosts but if it seems like iv mis understood that this will be tieing up connections for each long poll.

We use rack hijack, we don't tie up connections, 1000s of ongoing connections can be serviced from a single background thread. Your concurrency is way way way higher than 64.

[cheynewallace]

Ok, thats good to know, thank you @SamSaffron .. I was super happy to discover I didn't need a full blown web sockets setup to service a very basic piece of functionality. Realistically, if I could service a 1000 connections with my one machine, that would do me for a while.

Is there any recommendation as to the best config for callbackInterval and backgroundCallbackInterval in order to preserve connection resources? I assume lower numbers are better? Im a little confused how those two affect each other.

Great gem by the way Sam 👍 , thank you for building it