What's the most effective way to handle hundreds (300+) of users who join a single VC to be sorted?
The requirements:
- User joinsThe questions: - Is sharding an effective solution to this? I thought I read somewhere that sharding was only to load balance servers (i.e. 1 server with 20K users will be balanced to 4 servers with 5K users as a crude example). Would it be effective for a single server with hundreds of active concurrent user(s) who load it? - When sharding (I'm very ignorant on how sharding works, am currently doing some reading) but does it open multiple connections on the same hardware, or will I need to spin up more servers/instances? - Should I be using theVoice Channel A-Voice Channel Awill have hundreds of users join at once - Each user will need to be filtered (based on internal data from a database, have a local cache with sorting information) to another voice channel - There are currently 4 voice channels to be sorted to, channelsB,C,E,F, with possibilities of expansion in the future
voiceStateUpdate event to check when members join/leave in this case? Is the voiceStateUpdate event even an effective event to look at or am I missing something that is a lot more effective/efficient?
- If not sharding, I can implement a FIFO queue, but it would be slow I imagine, since I would have to rate limit myself- are there any recommendations/options to maybe bulk move users? (i.e. users 1-10 need to all be moved to Voice Channel C`)
- Is what I want even possible?19 Replies
- What's your exact discord.js
npm list discord.js and node node -v version?
- Not a discord.js issue? Check out #other-js-ts.
- Consider reading #how-to-get-help to improve your question!
- Explain what exactly your issue is.
- Post the full error stack trace, not just the top part!
- Show your code!
- Issue solved? Press the button!- is sharding a (...) solution for this?
no
- bulk move?
not a thing
yeah I figured- i just was having trouble wrapping my head around how exactly sharding works, thought the additional WS connection(s) would be something I could have leveraged
no, just spreads guilds across shards, so everything happening within a guild will go to the same shard
your use case has some additional issues regarding scaling
there is no "get members in this vc" endpoint, so indeed you will need to witness the voice channel update or fetch all members and filter by or associate to a given voice channel (here comes the scaling issue - a gateway request to receive all members can cause a ton of guild member chunk events to be sent, which may even back up the event queue to the point that the 3s-initial response for application commands cannot be sent (i have experienced that myself on servers with multiple million users))
How did you handle the join requests at such a large scale? Our team's initial thoughts was sending the data to one (or more) balanced worker applications with a main and api application handling the routing
if you can do it on a per-user basis as they join the issue basically vanishes apart from rate limits making it take some time - substantial time at larger scales
the case that hurts performance wise is knowing the current members of a vc after ready - also not an issue on smaller servers, can just take very substantial time at scale
The issue is that this is generally an infrequent event (only happens M/W/F @ 7 EST). What do you mean by a "per-user basis"? the
members property in voiceStateUpdate only returns a collection, and from what I can tell, there's no way to get an event with a single member on voiceStateUpdate
I could do a recurring state read of the channel I suppose, instead of listening to the event.... an interesting idea... hmm. Not a huge fan of timeouts/interval chains but maybe that's the most effective solution
wait.:event: (event) Client#voiceStateUpdate
[email protected]
Emitted whenever a member changes voice state - e.g. joins/leaves a channel, mutes/unmutes.yeah for some reason I am going into the channel property instead of taking the member itself..... 🤦♂️
based on cache
Well that's an easy enough fix- the issue still lies in moving everyone around. I wonder if worker applications will be the best solution here, like you guys suggested- gah that sounds like so much complex work
that isn't really... what
I guess I don't quire understand what you are recommending then- for worker applications, I would still have to manage and send the data to the applications for them to move
so i.e.
application a would have to tell application b to move user chave you implemented this feature?
what is the current, real problem?
if "it's moving people, but slowly", then what Q mentioned may be a solution:
A moves 1-5, 16-20
B moves 10-15, 21-25
or whatever measure/split you want, with 2 that'd cut the total time it takes to move all in half
if it's not that, then i'd suggest trying how fast it goes with 1 app and if that's already sufficient
the limiting factor here is the rate limit on
PATCH /guilds/:id/members/:id - the same issue one may run into when assigning roles to a ton of peopleLet me do some testing and i may come back to this
Also as a complete aside is copying links to posts disabled somehow here? I can't seem to get a link to this post
I also can't copy links to messages, which is odd, because I can do it elsewhere
just broken on discord atm
i cannot do it anywhere