daffl
commented
5 years ago In theory, yes, feathers-sync makes sure that all events get published to every server. However, each server instance will have to make sure that events only get published to the appropriate channels. It is very unlikely that every connected client will have to know about every event.
As long as your queueing mechanism (MongoDB/Redis etc) can keep up It then comes down to
- Channel publishing which is done in constant time (
O(1)) as long as you don't do any looping yourself - The internal NodeJS event system
The way both those things are implemented and perform makes it a very unlikely bottleneck. You will either first run into problems with the queueing mechanism or with websockets being unable to handle that much of a load.
ashconnell
stale[bot]
Please correct me if I'm wrong but this is how I understand the implementation:
If feathers-sync sends every event to every server instance then doesn't that mean your instances get diminishing returns as you continue to scale?
As an example, say I have 2 small instances, each instance can handle around 500 active users at once. Let's say each user is creating a document every 5 seconds. This means every 5 seconds 500 events are published per instance, and 500 events are received by each instance. This seems feasible.
But now let's ramp this up to 10 instances, again with each having 500 users and each user creating a document once every 5 seconds. This time, every 5 seconds 500 events are published per instance but 4500 events are received from the other instances. This is quite a heavy load.
One option here is to then reduce the amount of users each instance handles, to allow more computational power for the incoming events. But this can only go so far before it's 1 server handling a single user and millions of events per second.
Is this an accurate depiction of how feathers would scale?