Is there a benchmark for maximum chat channels possible? Do they use memory/cpu just being open (and if so, is there a difference in memory/cpu usage for the 3 different types)?
There is a possible case in the game I am working on where there could be 500+ non persistent chat channels per match… which would lead to an expected 50,000 chat channels server wide. I am assuming they close automatically when there are no active players in that chat online, right?
Another way I would handle this, if it’s just too much, would be to use the same chat channel for the entire game but with different properties so that I can separate based on those properties. It would mean everyone would receive the messages and more data being sent overall so I wanted to check in to see if it the original number was possible.
i found that the chat is very performant and also works detached from the match handler.
but i can say that messages are not purged automatically. They even persist server restarts/redeploys. (Which is obvious because they are not at all attached to match handler logic)
But why would you need so many channels? You may use “Direct Messages” for 1:1 communications, or (client relayed) match handler for any realistic game handling cases where the client does all the hard work. A main benefit of Chat is IMO that messages get stored; this should not be the case with game-logic / packets. You have State for this.
Since Chat is build on top of Sockets like multiplayer handling in general, i expect it to have the same concurrent-connection limits.
@dela
I am using Nakama in a very unconventional way relative to how it is seemingly made to be a social system. Everything is supposed to be match based with no persistence - think kahoot but with decision making and server logic.
Just so happens the game also heavily relies on communication between teammates within a match so I’ve been using the chat channels with persistence set to false.
All in all theres about 500 total chat channels (some are 1-1, others are rooms) - but your point gives me an idea of changing from using chat channels to just processing messages through the match handler itself. Although that would depend if there is any downside to having so many individual chat channels but I can’t find anything regarding it on the docs
Also only reason I am using nakama vs some other solution, was because of its performance, scalability, price, and compatibility with WebGL.
A LOT of other solutions fail in at least one of these aspects (usually in the price and webgl support).
Running Unity based servers (using stuff like fish-net) is also somewhat viable but then I would have to design the scalability myself without guarantee it would be better than Nakama. At the very least, Nakama is somewhat guaranteed to support over 10k players in 1 tick rate matches
ok i understand your case and indeed already know kahoot.
But if i understand correctly you use some kind of event-based logic (chat message=event action). You maybe take a step back and think about handling stuff not event-driven but state-driven. Broadcasting a single (shared) state object across all clients makes your server logic much more robust, scalable and as such performant.
That may not be possible in your case, but i dont know your requirements. I just informed you about it
It just came to my mind, that you may also use a Redis Pub/Sub which is the most powerful “chat engine” you could imagine
