#How are you guys realizing horizontal scaling with djs?

41 messages · Page 1 of 1 (latest)

sour dove
#

Hey everyone!

We're facing a bit of a puzzle on our end. Tired of the server upgrade routine, we're playing around with the idea of spreading our workload across smaller servers for a more horizontal setup. The potential perk? It could be a game-changer for our budget.

Now, here's where it gets interesting. Djs, isn't quite on board with the whole selective shard handling thing straight out of the box, unlike some other libraries like Serenity for Rust.

We're not stressing about it, though. We're just curious – how are you handling this in your setups? Any ideas or solutions you've stumbled upon?

Let's have a chat about it. ^^

Appreciate it a ton for joining the conversation!

Best, conny.

fallen tulipBOT
#
  • What's your exact discord.js npm list discord.js and node node -v version?
  • Not a discord.js issue? Check out #1081585952654360687.
  • 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!
stray arrow
#

Huh? You can pass shards: [0,3,7], shardCount: 12 in client constructor without issue and have your selective shard handling. Unless you mean something different?

sour dove
#

Oh my this is a thing by now? To be completely honest, i haven't looked into shard handler changes since djs12 or so

#

hmm to be fair, i still can't find that in djs's guides. However, i will try it out. This might be exactly what we're looking for. thank you!

stray arrow
#

v12 had that already too…

#

For documentation on those options

sour dove
#

Thats very interesting, where are ClientOptions being utalized?

I thought this might be a part of the ShardManager, is it not?

stray arrow
#

You don’t need a ShardingManager at all for that, if you spread them to different servers. Each server will run their own Client. And ClientOptions are the options you pass in Client(…) constructor

#

The question is how and if your shards need to communicate with each other though

sour dove
#

They don't really.

But would i still be able to use a sharded model, to - f.e. - just half my workload? So to say run 50% on one server and on another the rest?

stray arrow
#

In other words: do you currently use broadcastEval or fetchClientValues?

stray arrow
sour dove
#

Yes haha

but you told me the shard manager is not required. can i still use it tho?

stray arrow
#

shards: 0, shardCount: 2 on the one server
shard: 1, shardCount: 2 on the other server
v14 has internal sharding in worker mode too, if you want to have your shards running in different (worker) threads. If for some reason you need to have the shards run in totally separate processes you can do that with a ShardingManager, but I‘d like to hear the reason why you think you need it

sour dove
#

It's honestly just way i have done it since ever. There is no explicit reasoning behind it.

How would i run such an infrastructure? I would get rid of the sharding manager and "plop" the shard informations into the client options instead?

stray arrow
#

Yes

sour dove
#

like this for example?

image.png
stray arrow
#

No. In the client constructor

sour dove
#

oh right

stray arrow
#

const client = new Client({…, shards: […], shardCount: …});

#

Get the shards from an env file or config.json and you can still run the same code on all servers

sour dove
#

excuse my scepticism, i've been working with the shard manager all this time and apparently i could've spared me some valuable time.

#

Just for my curiosity tho, if i wanted to use the shard manager, i would now declare that information in the client directly right?

i would assume i would use the property hightlighted in my screenshot?

image.png
stray arrow
#

Indeed. Internal sharding was added later than the ShardingManager and it used one single-threaded node process for most of the time only. So for big bots it‘s not suitable to run one single Client only. But if you want to horizontally scale you would run several processes anyway

stray arrow
#

Unless you specify worker mode

#

But if you want worker mode you really should use internal sharding with worker mode enabled instead

sour dove
#

The worked mode is enabled by default when utalizing the method mentioned above? (Shard list in client constructor)

stray arrow
#

If you don’t mind me asking: how many guilds are we talking, so how many shards do you have/how many small servers do you plan to use?

stray arrow
sour dove
#

Currently we're talking 22 shards with approx. 33k servers in total.

We're just playing with the idea to make sure we're clear for the future ^^

sour dove
#

might be a silly load of questions im dropping here, excuse me haha

stray arrow
#

In the ws: property of ClientOptions you‘ll be able to set the buildStrategy

dapper widgetBOT
#

interface WebsocketOptions
WebSocket options (these are left as snake_case to match the API)

sour dove
#

i can't help but to feel like im trying to imitate what the shard manager would already do by itself

#

regardless, do you have an example of an implemented custom build strategy function for me?

#

How are you guys realizing horizontal scaling with djs?

stray arrow