2y ago

How will lemmy scale?

I already get rate-limited like crazy on lemmy and there are only like 60,000 users on my instance. Is each instance really just one server or are there multiple containers running across several hosts? I’m concerned that federation will mean an inconsistent user experience. Some instances many be beefy, others will be under resourced… so the average person might think Lemmy overall is slow or error-prone.

Reddit has millions of users. How the hell is this going to scale? Does anyone have any information about Lemmy’s DB and architecture?

I found this post about Reddit’s DB from 2012. Not sure if Lemmy has a similar approach to ensure speed and reliability as the user base and traffic grows.

https://kevin.burke.dev/kevin/reddits-database-has-two-tables/

56 comments

Bigger instances will indeed run multiple copies of the various components, it's pretty standard software in that regard.
Usually at first that will start by moving the PostgreSQL database to its own dedicated box, and then start adding additional backend boxes, possibly adding more caching in front so that the backend doesn't have to do as much work. Once the database is pegged, the next step is usually a write primary and one or more read secondaries. When that gets too much, you get into sharding so that you can spread the database load across multiple servers. I don't know much about PostgreSQL but I have to assume it's better than MySQL in that regard and I've seen a 1 TB MySQL database in the wild running just fine.
I think lemmy.world in general is hitting some scalability issues that they're working on. Keep in mind the software is fairly new and is just being truely tested at large scale, there's probably a ton of room for optimization. Also lemmy.world is still on 0.17 and apparently 0.18 changed the protocol a lot in a way that makes it scale much better, so when they complete that upgrade it'll probably run a lot better already.
The part that worries me about scalability in the long term is the push nature of ActivityPub. My server is already getting several POST requests to /inbox per second already, which makes me wonder how that's gonna work if big instances have to push content updates to thousands of lemmy instances where most of the data probably isn't even seen. I was surprised it was a push system and not a pull system, as pull is much easier to scale and cache at the CDN level, and can be fetched on demand for people that only checks lemmy once in a while.
I need to start digging into Lemmy's code and get familiar with the internals, still only a couple days in with my private instance.
- I don’t have a coding background but this was very informative. Thanks for sharing
- Would it be feasible to change it to a pull system at this point? I don't think the Lemmy part of that is a problem, but ActivityPub may need to make big changes and I'm not sure how practical that is.
- The implementation as far as I understand it is plain stupid. It prevents small instances from participating at any significant scale and seems happy to just drop data over the wire without reconciling. Seriously amateurish.
  
  I'm not sure about the data being dropped, my instance was misconfigured for a day or two, and as soon as I fixed it, the data came right in. Instances repeatedly trying to push data to my instance is what clued me in that something was missing from my NGINX config. It backfilled pretty fast.
  Although I wouldn't mind if there was a fallback pull mechanism to remediate failed pushes.
- The part that worries me about scalability in the long term is the push nature of ActivityPub. My server is already getting several POST requests to /inbox per second already, which makes me wonder how that's gonna work if big instances have to push content updates to thousands of lemmy instances where most of the data probably isn't even seen. I was surprised it was a push system and not a pull system, as pull is much easier to scale and cache at the CDN level, and can be fetched on demand for people that only checks lemmy once in a while.
  I think there's a benefit to the push model, as the instances can prioritize who to push to first if there's scaling issues, instead of having to throttle GETs, effectively the end result is anyway the same that nothing ends up to other instances in real time (which is fine). I don't know how lemmy works exactly, but could the push model just be a detail of activitypub https://flak.tedunangst.com/post/what-happens-when-you-honk ?
  
  It definitely is part of the ActivityPub protocol, but I only glanced at the spec so far. I should probably follow that link and implement a toy ActivityPub app to get more familiar with how it works.
  I think there’s a benefit to the push model, as the instances can prioritize who to push to first if there’s scaling issues, instead of having to throttle GETs,
  The downside to this is smaller instances are penalized in that scenario, which would in turn could cause users to flock to megainstances until it becomes centralized again.
  As I said, GETs are cacheable, so if one slaps Cloudflare in front you can handle millions of GETs for relatively cheap.
  Maybe it's batched however? I really need to read the spec. Pushing to thousands of servers every 1/5/10 minutes certainly would give a fair amount of headroom to make it work I guess.

As far as I’m aware lemmy does not support load balancing or high availability as it currently stands. But development is still in its infancy and I’m sure that’s a top priority
- I don't think it officially supports it but it does work! Lemmy.world is currently running on multiple containers load balanced by nginx. look at u/ruud latest post about it
- It's not only about scaling a single instance, but scaling the fediverse.
  Currently, each instance sends all events to all federated instances. That means, essentially each instance needs to store and process a significant part of the entire fediverse. That's insane and has to be addressed.

My expectation, or at least hope, is that Lemmy will grow horizontally, i.e. more instances for more specialised content, instead of vertically, i.e. more communities in singular, larger instances. Since it's all federated, you can get to stuff in other instances.
I just had an idea. Let's compare reddit and lemmy as land use metaphors.
Reddit is like one monolithic megacity. It's full of communites, some big, encompassing entire neighbourhoods, and others smaller, having one street, one block, maybe even just one building.
Lemmy is like a country, with every instance a city. Some cities are big and varied, others are smaller and specialised, like ones dedicated entirely to fishing or aviation or being German. And you can choose a city to settle in and move between cities for your content. Some cities will be more open to sharing content with residents of other cities, and others will put up bigger restrictions. There are jokes about parts of the userbase on 4chan or Tumblr forming their own subcommunities, and the fediverse allows this in a very material way.
My expectation is that more cities may emerge as people develop more specialised communities. And since there are many cities, there is some resilience in the system. If an instance goes down, you've lost one instance. Out of christ knows how many. Chances are some of its content is duplicated across other instances, so nothing of value is lost. Meanwhile, if (/when) Reddit goes down, all of Reddit is gone.
In short, I hope lemmy develops more, smaller, specialised instances over time. Reddit allowed very niche insterests to have a corner, and despite that, I think the fediverse is more suited to allow for that than a centralised service.

Poorly. Lemmy will scale poorly.
I won't be surprised if the larger instances start locking down more as a way to sustain themselves, like restricting communities or only allowing text posts.
- Sometimes you have just to accommodate to the situation and keep going until it settles down. The error I think here is thinking something can’t have flaws and issues, even more if it’s not behind a corporations. And no one wants corporations.
  
  It isn't about accommodating to the situation, but planning for long term growth.
  Right now, instances of Lemmy don't have any way to fund server costs other than asking for donations. Outside of Wikipedia, that isn't a sustainable business model. How is Lemmy supposed to survive if, every time a sub gains critical mass, it shuts down?
- Wouldn't that create a natural balance though? A large instance starts struggling so people are incentivised to move to smaller instances or start new instances and so spread the load more evenly. That's how it would scale. I'm surprised how many of the larger instances haven't closed signups yet but that wouldn't be a bad thing if they did.
  
  The issue isn't on the user end, but the sub end since that is where all the data is stored.
  So, according to your proposal, the best thing a sub should do when it is getting popular is to go private with its existing subscribers and any new people who want to participate should go create their own sub in a different instance.
- When the protocol favors monoliths, we're right back to the Reddit problem
  
  Scalability doesn't mean "favoring monoliths". It's just scalability and honestly, 60k users shouldn't bring a service down. 60k users is not even close to being a monolithic instance.

Education probably. Back in the day people didn't have any problem understanding that different forums had different capabilities. When MMOs were in full swing, people didn't have problems understanding what being on thr popular server during peak hours meant.
Everyone has just gotten too used to centralization with a lot of money behind it. Eventually people will adjust their expectations. Even if Meta's fediverse attempt takes off, there are always going to be niche communities that exist outside of those spheres, so if people want that, they'll have to move.
The point of the fediverse is having a choice. Some people are going to chose megacorp of the week's offering and that's okay as long a little pockets exist for when people get mad at the megacorp. Also federation leaves space for multiple dominant platforms in a way the current system doesn't.
In short, eventually some instances are going to be bankrolled either through a robust crowdcourcing effort or through being a company. That's okay. The purpose of the fediverse is to allow for smaller niche ideas to be able to breathe without having to adhere to one group's ideals. "If you don't like it, make your own" is a fair statement now

The way i see it the best way forward would be each community runs there own instance and what we now call communities should become subtopics of that community.
So for example. Asklemmy could be an instance and its members are all people who believe in the value of that instance and want to be involved in sustaining it.
Explainlikeiam5 could be a subcommunities of this instance because its philosophy is largely the same. If asklemmy has plenty of scientist members they could open a askscience subcommunity too.
The majority of user traffic would all come from other smaller homerun instances.
Big instances that try to be everything at once are a side effect of the massive growth we are experiencing, they work now but will slowly become more centralized and are therefore doomed to fail (in my opinion)
To recalculate. How can we help Lemmy grow? By being proactive users that maintain something small we chose to care about.

It’s a challenge, for sure. It is known that there are some inefficiencies in the codebase, which are actively being worked on. But besides that, it’s tricky to know where bottlenecks are until the user influx happens, particularly with the novel federation architecture. Maybe it’s impossible to scale, maybe not, but we only now are seeing a testable use case. I would expect optimization work to start bearing fruit, but these thing take time.

Well, I run an instance, too. It's not big at all, but I was thinking about the issue of scaling, too. You can only scale up a single server so much...
But on the other hand, Lemmy is still young. We'll find solutions to that problem.
Also, interesting article. I only took a glance at it, but having only two tables kind of suggests that Reddit is using a relational database. So, if they're not "normalizing" everything, why not use a completely different paradigm, like what MogoDB etc. has?
- The database isn't really the problem in the current state of things. The server is because:
  Until 0.18 there was no caching (for the UI) and the poorly implemented websockets
  The developers have admited that they aren't proficient in SQL, in which case, why not using an ORM instead? Sure, they aren't perfect but they will do better than the average developer at scale.
  There is no queue system for activityPub requests
  Because there is no queue, user requests and federation have the same priority when it shouldn't and one can bottleneck the other
  Live inserts are used meaning that regardless of the DB used, performance is going to be killed since inserting data 1 at a time several times a second is a major waste of resource
  Tl;dr: It's trying to do everything and not that well. So users suffer because they have to share resources with non-UI related tasks.
  The database suffer because it has to do an insert of 1 object X 50 times in a second when it could do it once for all 50 items.
  Federation suffers because you can't offload it to a seperate machine farm whose job will be to receive and send ActivityPub requests and send/read data from the correct queues to do so.
  
  Federation also does a lot of live HTTP connects to other peers. It looks up users for messages. The whole design is very resource intensive, one single vote, comment, post at a time. There is also a lot of boilerplate JSON overhead in sending something as simple as a single vote.

60,000 users is also a LOT for a Lemmy instance. They've gone from ~8,000 to 60k+ in a matter of weeks. I'm sure there will be many performance and efficiency improvements coming soon. Hopefully people spread out a bit more across other instances with less users!

I love Lemmy but your question is legit. I just signed up with lemmy.world because lemmy.ml is slow/not responding.
Before making a post in lemmy.world guess what? lemmy.world isn't responding. I know they have scheduled maintenance at 9 CET but it was 20 minutes before that.
- I just signed up with lemmy.world because lemmy.ml is down.
  lemmy.ml has been a slow-motion train wreck all June with errors and failing to send out federation copies. This asklemmy community is homed there, and a lot in the past 24 hours is missing.

Lemmy uses PostgreSQL, with a number of tables. It's pretty standard stuff, looks like, and it's in Rust. It's assumed there's only going to be one server per instance right now, but I'd expect that one server could keep up with a reasonable volume.
I already get rate-limited like crazy on lemmy and there are only like 60,000 users on my instance.
Is that a typical number of users to have already? Wow, we really are growing.
Rate limiting is it's own thing, I guess some work will need to be done to find a non-exploitable way to do it that still scales.

It'll scale horizontally, like E-mail. Lots of different servers operated by various entities. There may be some big players, like Outlook or Gmail, but overall there could be thousands of instances.

Since Mastodon is using ActivityPub too. How it worked after Elon?
- Mastodon is a couple years older than Lemmy, it was already a fairly mature product. People are thinking Lemmy is badly coded but we're all using a beta product with no user limits.

The ideal way that ActivityPub federation works IMO is a bunch of smaller nodes coming together to make a large network.
If you have a bunch of people all on one or two instances then you'll have a "central hub" of the network that's constantly overloaded.
That's my advice to community builders on this platform... Spread out across smaller instances, don't just all sign up to a big one.
- Moving the scaling problem from a few instances to federation is likely to cause more harm than good.
  I don't see how syncing a post across a hundred instances is more efficient than having a hundred users see the post on one instance.

Larger instances will have to monetize to stay afloat. I've gone so far as to buy a domain that is very appropriate for a business-oriented Lemmy instance (specifically for job hunting and career development), but don't yet have time or resources to take it to the next level.
- Who says any instances need to grow?
  
  I said 'afloat', and was specific about larger instances.

Lemmy is entirely open source, so you can see what their architecture looks like, etc.. here: https://github.com/LemmyNet/lemmy.
Rate limits, as I understand them from the code, should only apply on a per-IP basis. So you should only be seeing rate limit errors if:
your behind a CGNAT and multiple people who use your ISP are using Lemmy
you're sending A LOT of requests to your instance yourself
the admin of your instance has significantly lowered the rate limits (viewable here: /api/v3/site)
- I'm not an expert, but I thought the issue was generally that big instances like lemmy.world were getting overloaded on the server side, not that they were enforcing a manufactured rate limit on individual IPs.
  Also, someone else mentioned that on the fediverse even simple things like an upvote are slower and require more work here than in centralized platforms because they must be sent to all the instances that are indexing that user/community. As I understand, that's inherent to the fediverse, a bug not a feature, designed for redundancy and resilience.
  Again uninformed, but Lemmy seems like it should scale fine. Bigger instances will monetize, driving prospective users to smaller instances, and then rate limiting and server lag won't be so bad anymore.
  
  I’m not an expert, but I thought the issue was generally that big instances like lemmy.world were getting overloaded on the server side, not that they were enforcing a manufactured rate limit on individual IPs.
  From what I can see it's both. lemmy.world and others are getting overloaded, but there is an inherit built-in rate-limit in the code itself. You can see what those limits are via the api/v3/site. Now in theory if you're actually getting rate-limited you should be seeing HTTP 429 responses from the server. If the server is just overloaded, you'll get a 5xx response, the request will just timeout or at best you'll still get a response but after a significant delay (what most people are seeing).
  Also, someone else mentioned that on the fediverse even simple things like an upvote are slower and require more work here than in centralized platforms because they must be sent to all the instances that are indexing that user/community. As I understand, that’s inherent to the fediverse, a bug not a feature, designed for redundancy and resilience.
  I don't want to comment on this too much as I'm not an expert here, but here's how federation / ActivityPub works from what I understand looking at the code:
  Whenever you take any action (or activity) your browser will first send that message to your instance. If your instance then owns the community that message is then propagated out to EVERY linked instance listed here: /instances / api/v3/federated_instances. If your instance doesn't own the community, that message is forwarded off to the instance that does and they sent it out to EVERYONE on their federated instances list. As you can see this creates A LOT of network traffic.
  This posing an interesting problem... the number of ActivityPub messages goes up as the number of instances increase. But at the same time as more and more users join a single instance that require that that instance send more and more traffic to individual user's browsers as they view and respond to posts. So the problem here is trying to find a good balance. And to top it off, the default behavior of most users is going to be to join the largest instances, making that instance incur more and more traffic to view content.
  Again uniformed, but Lemmy seems like it should scale fine. Bigger instances will monetize, driving prospective users to smaller instances, and then rate limiting and server lag won’t be so bad anymore.
  Will it though? How would an individual instance monetize? They would have to use donations. If an instance tries to add Ads, users will leave to an instance that doesn't, making it so that they don't get any income. They could charge a subscription fee, but again users would just leave and the admins get nothing.
  The ideal configuration of the fediverse as I see it, is if we had two types of servers 1) content servers that only hosted communities but didn't have any real number of users, and 2) user servers that have no communities but most of the users. This way the number of API requests between instances is rather limited. When you end up with a server that has both most of the content and the userbase, the workload of that server appears to grow exponentially instead of linearly as the number of new instances rises.

56 comments