King

joined 1 year ago
[–] [email protected] 2 points 1 year ago (2 children)

Thanks for checking.
We don't need full database replication. We are just replicating activities that other servers are subscribed to. So the Comments table, only some of the rows will be "replicated". Not sure if/how CouchBase handles this.

[–] [email protected] 2 points 1 year ago (6 children)

Can you provide a link? Only thing I see on Couchbase is for NoSQL databases.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (1 children)

Thanks for doing all this.

Do we have any real numbers from a real server? How many votes are trying to be federated to how many servers?

Just ballparking some approximate numbers:

  • [email protected]
  • 15k subscribers
  • 4000 subscribed servers
  • 10 votes per subscriber per day

15000 * 4000 * 10 = 600,000,000 federated actions. That is around 7,000 per second 24/7 for one community.

IMO, this real time federation just doesn't scale. We need to start planning the specs for federation batching.

[–] [email protected] 1 points 1 year ago (1 children)

My instance is missing both comments to this post. https://vlemmy.net/post/376384 versus https://lemmy.ml/post/1605318

[–] [email protected] 3 points 1 year ago

Buying $10000 of Apple stock in 1997 wouldn't really move the market. TSLA, GOOG, AMZN, MSFT, NVDA, and so on. Lots of stocks where I could buy a small about and get 500x-1000x returns some 10 years later.

[–] [email protected] 4 points 1 year ago (1 children)

I remember reading an issue where the scheduled task to update hot and active was breaking shortly after reboot. So those lists were getting frozen in time, until the next reboot.

[–] [email protected] 1 points 1 year ago

The node still needs to receive every subscribed federated action and insert it into the local database. This has to be local to the "main application server". Your proxy servers don't reduce the number of federated actions. It only reduces the number of servers needed to communicate with.

I feel that the bottleneck will be the total number of federated actions, not which servers deliver them.

[–] [email protected] 1 points 1 year ago (2 children)

I believe the current implementation wont scale because instances won't be able to handle every subscribed federated action. Having a hub server doesn't reduce the number of subscribed federated actions, only whom they come from.

[–] [email protected] 5 points 1 year ago (13 children)

There is no need to "maintain all of the connections". The server opens a connection, sends the data, then closes the connection.

[–] [email protected] 14 points 1 year ago (15 children)

Yes, it is a "full mesh" diagram. But for each specific "federated" action, it is a simple hub and spoke distribution. The hosting server will send the federated action to each subscribed node. The nodes don't need to check in with each other for that specific action.

I too believe that Federation is going to have scaling issues. But not due to full mesh