When you subscribe to a different instance, it can take time for the subscription to be sent to the server you’re subscribing to.
Sometimes, that data never even makes it.
Honestly, “Subscribe Pending” doesn’t change much, it will still show posts in your feed, and you can still make posts and comments to the community.
However, like the “subscribe pending” issue, you may end up with some comments showing up, and others never showing up, on the instance you’re posting to.
I’ve had lots of troubles with the random nature of which comments of mine post to other instances. with beehaw and lemmy.blahaj it is seemingly at random if a comment will show up on their instance or not. When I go visit threads on beehaw or blahaj and not through lemmy.ml, sometimes comments show, sometimes they don’t. It really is random and just whether or not the data made it through.
These are small servers run by volunteers and they don’t have racks and racks of failover servers like reddit. The amount of data passing back and forth between instances is HUGE and it seems like a lot of that data is getting “lost” in the transit, resulting in things like missing comments or “subscribe pending.”
These are part of the growing pains of a federated service.
What are the backend protocols for federation? I wonder if it’s true server load (physical lack of compute) or something like network bottlenecks (which we might be able to see by using things like NIC utilization and error rates).
Network bottlenecks may be addressable at the protocol layer with improvements to how federation works.
I’m pretty damn sure its physical lack of compute, because lemmy.ml already massively upgraded their server two weeks ago to account for this, and it’s already overloaded again.
Also, this was an issue early on in Mastodon as well. The more federated servers there are, the more each server has to communicate with every other server which apparently eats up RAM and CPU cycles. So each time there’s an update, it has to sent it to X number of servers, and retrieve data from X number of servers, and as X climbs, the more network activity and CPU cycles to handle it there is. A lot of requests in waiting can be stored away in RAM, but even RAM has limits.
Finally, the newest server version was supposed to help ease this kind of stuff by moving from using WebSockets to HTTP. Pretty sure the federation protocols are all just HTTP, but I could be wrong.
Federation.
When you subscribe to a different instance, it can take time for the subscription to be sent to the server you’re subscribing to.
Sometimes, that data never even makes it.
Honestly, “Subscribe Pending” doesn’t change much, it will still show posts in your feed, and you can still make posts and comments to the community.
However, like the “subscribe pending” issue, you may end up with some comments showing up, and others never showing up, on the instance you’re posting to.
I’ve had lots of troubles with the random nature of which comments of mine post to other instances. with beehaw and lemmy.blahaj it is seemingly at random if a comment will show up on their instance or not. When I go visit threads on beehaw or blahaj and not through lemmy.ml, sometimes comments show, sometimes they don’t. It really is random and just whether or not the data made it through.
These are small servers run by volunteers and they don’t have racks and racks of failover servers like reddit. The amount of data passing back and forth between instances is HUGE and it seems like a lot of that data is getting “lost” in the transit, resulting in things like missing comments or “subscribe pending.”
These are part of the growing pains of a federated service.
What are the backend protocols for federation? I wonder if it’s true server load (physical lack of compute) or something like network bottlenecks (which we might be able to see by using things like NIC utilization and error rates).
Network bottlenecks may be addressable at the protocol layer with improvements to how federation works.
I’m pretty damn sure its physical lack of compute, because lemmy.ml already massively upgraded their server two weeks ago to account for this, and it’s already overloaded again.
Also, this was an issue early on in Mastodon as well. The more federated servers there are, the more each server has to communicate with every other server which apparently eats up RAM and CPU cycles. So each time there’s an update, it has to sent it to X number of servers, and retrieve data from X number of servers, and as X climbs, the more network activity and CPU cycles to handle it there is. A lot of requests in waiting can be stored away in RAM, but even RAM has limits.
Finally, the newest server version was supposed to help ease this kind of stuff by moving from using WebSockets to HTTP. Pretty sure the federation protocols are all just HTTP, but I could be wrong.