this post was submitted on 15 Jun 2023
21 points (100.0% liked)

Meta (lemm.ee)

3595 readers
1 users here now

lemm.ee Meta

This is a community for discussion about this particular Lemmy instance.

News and updates about lemm.ee will be posted here, so if that's something that interests you, make sure to subscribe!


Rules:


If you're a Discord user, you can also join our Discord server: https://discord.gg/XM9nZwUn9K

Discord is only a back-up channel, [email protected] will always be the main place for lemm.ee communications.


If you need help with anything, please post in !support instead.

founded 2 years ago
MODERATORS
 

Hello, fellow lemmings!

I have a few quick updates about lemm.ee. If you don't want to read a wall of text, then the key points are summarized here for you:

  • There is a Lemmy upgrade (0.18) on the horizon, executing this upgrade will require downtime for lemm.ee
  • I have made some improvements to our infrastructure in order to reduce those pesky 404 errors that some users have been seeing
  • It's already looking like ~15% of our infrastructure bill for this month is going to be covered by community funding. A huge thanks to all financial supporters of lemm.ee! It's extremely heartwarming to see that people believe in this platform and are willing to share the costs with me.

Upcoming 0.18 upgrade

With the next version of Lemmy nearing completion, I am starting to plan the upgrade for lemm.ee.

With the 0.17.3 -> 0.17.4 upgrade, I was able to keep lemm.ee online during the upgrade with no downtime. That's how I would prefer to do all upgrades in the future as well, but unfortunately, there are some fundamentally incompatible changes in 0.18. This means that running a mix of 0.17.4 and 0.18 servers in our infrastructure at the same time will not work - effectively meaning that we can only execute this upgrade with some downtime.

In order to keep surprises to a minimum, I am planning to create a post with a title like "When this post is 1h old, the server will go down for an upgrade". Once 1h has passed from that post, you will be unable to access lemm.ee until the upgrade completes. If everything goes smoothly, then total expected downtime will be around 15 minutes, but in case of any issues, it could be slightly longer!

It's not clear yet when 0.18 will be fully ready, but if everything goes well, then this could already happen as early as next week. I will keep you all posted!

Why do we even want 0.18?

There are some very important optimizations landing in 0.18, which should help make the Lemmy UI feel considerably snappier and at the same time give the backend servers some much-needed breathing room. This should help take a lot of pressure of the federated network as a whole, and is a good first step towards scaling further.

Additionally, there are some key fixes that AFAIK will all land in 0.18, such as:

  • Additional posts will no longer automatically appear in your feeds while you're scrolling
  • You should stop getting redirected onto a completely different post when opening other posts in other tabs
  • The front page will stop showing stale posts for all instances (lemm.ee users will have been enjoying this patch since yesterday already, as I am the author of the patch and decided to apply it early here πŸ˜ƒ)

All in all, 0.18 is looking like a great upgrade, so I’m personally looking forward to it.

Random 404 errors

Several users have been experiencing errors on lemm.ee (and similarly on other instances) where some page loads will fail with a white page and a 404 error.

I have spent some time debugging and attempting to mitigate this issue today. I have identified the root cause (spikes in database load related to the amount of new posts in the federated network for every 5 minute interval), and after some database tuning, I have managed to significantly mitigate this issue. Previously, this issue was appearing for about ~6000 page loads every hour. In the hour following my changes, this error only appeared for roughly ~596 page loads! It’s still not 0, so I will continue to try and improve this, but we are starting to brush up against the limits of what our current database infra can manage.

In the longer term, we will seriously benefit from any Lemmy optimizations - I am hopeful that even 0.18 will start bringing down the load on our servers. Additionally, we have a lot of room to upgrade our database infrastructure, but of course this would mean increasing the budget, which I’m not in a position to do for now. This segues us nicely into the third and final topic I wanted to cover:

Server costs

As of today, our infrastructure has scaled up to the point where my own budget will allow. To be more specific, I am able to keep the servers running as is indefinitely, but I am not able to make any further upgrades to our servers out of my own pocket.

Thankfully, we have some extremely kind members in our community, who have already decided to begin supporting lemm.ee and thus ensuring that every single one of us can enjoy a well functioning platform and potential further upgrades down the line! As of today, we have 4 supporters who have signed up for monthly (!!) contributions on my GitHub sponsors as well as one supporter who has donated money through my Ko-Fi page. I want to seriously thank each of you! I am personally super excited about Lemmy as a network, and specifically lemm.ee as an instance, so I’m truly happy to see that others share this excitement and are willing to join me in funding all this.

Pinning updates on the front page

Finally, I am looking for some feedback on how you feel about update posts such as this being pinned to the top of your lemm.ee front page.

My current plan is to pin this post on the front page for the next ~24 hours, after that, I will unpin it, but you will still be able to find it in [email protected].

I have seen some comments complaining about too many pinned posts, so alternatively, I could start pinning the latest site update post to the top of the !meta community, and avoid pinning it to the front page altogether.

If you have thoughts about this (or anything else I have mentioned), please comment below!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (3 children)

That's greatly appreciated!

In terms of costs of scaling, I would say we're positioned a bit better than many other Lemmy instances at the moment, thanks to the fact that we employ horizontal scaling as much as possible for the Lemmy software itself.

By the way, AFAIK, lemm.ee is the only non-experimental Lemmy instance that has chosen to go with horizontal scaling so far. If anybody knows of any other instance that is doing it, I would be super interested to know about it! All the admins I've spoken to so far myself have confirmed that they are only doing vertical scaling.

More technical details below for anybody who is interested:

There are two approaches you can generally take for scaling - horizontal, where you add more load balanced nodes of more or less the same power, or vertical, where you increase the power of an individual node (of course a mixture of both is also possible).

One of the benefits of horizontal scaling is that in most cases, it's significantly more flexible compared to vertical scaling. For example, at my current cloud provider, the only upgrade path for vertical scaling a server would be 8 CPU -> 16 CPU - 32 CPU -> 40 CPU. So if you're on a 16 CPU server, and you need just a little bit more headroom, then your only option is to upgrade to the 32CPU server, which is straight up double the power (and cost!). Meanwhile, with horizontal scaling, you can just keep adding smaller servers (say 2 CPU each) one at a time, thus growing costs more gradually and appropriately for your actual needs.

So for lemm.ee, this horizontal scaling means that when our backend servers start getting overloaded, I can just add one or two more servers without exponentially increasing costs.

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

As someone who has "been there and done that" at a much larger scale than many devs may ever get a chance to (not a brag, it can suck royally) this really seems like the smart choice.

This is effectively a basic web server scenario and horizonal scaling tends to with really well to a point. And frankly it'll be a long while before that becomes the bottleneck.

Smart choices you're making. All the best and I'm happy to help out monetarily where I can!

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

Are your servers in one geographic region? Could you scale across regions for better performance?

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

Personal opinion is that is outside the scope for a single instance. The whole idea behind Lemmy is to have multiple instances to accommodate different geos and different languages.

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

I am already leveraging Cloudflare's globally distributed cache, which helps improve performance even if you're far away from the backend server. But this only helps partially, not with all types of requests.

lemm.ee is hosted in central Europe, and based on monitoring, it does seem that most users are having a pretty decent experience on lemm.ee regardless of their geographic location so far. One key exception to this are short windows of database load spikes, which last for roughly 10 seconds every 5 minutes. For these spikes, everybody is suffering equally, regardless of where they are in the world πŸ˜….

But in general I agree with the sibling comment by @Notorious - rather than scaling one instance to be some massive globally distributed powerhouse, it makes sense to spread out the load amongst a lot of different instances.

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

Are the DB spikes ACTUALLY every 5 minutes or is that just kind of a guess? I ask because if it's consistent, it's gotta be some sidecar process somewhere in the stack that can be fiddled with.

That said, it really sounds like you know what you're doing already so I'll just go play with my new communities.

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

The spikes are caused by a specific reoccurring process which happens every 5 minutes. I have already significantly optimized it with a patch on lemm.ee, I'm working on getting it merged upstream as well!

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

For storage, I can understand how horizontal scaling works (add more storage nodes to, say glusterfs). But how does it work for CPU? Since adding a 2CPU VM can be physically on another server, it would need lemmy to work in a highly distributed manner, i.e., CPU instructions need to cross the network.

Is this distributed feature a part of lemmy or is there another abstraction layer?

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

This is where our load balancer comes in. All requests go through the load balancer, and this load balancer will try to evenly distribute the requests to all of our backend servers.

Is this distributed feature a part of lemmy ... ?

In fact it's the opposite - Lemmy has so far had some assumptions built in to the code which make it quite hard to run on multiple servers. I have made some modifications in order to improve this (and contributed those modifications back to the main repo as well). It's one of the things I want to keep improving as we grow.

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

Here is my oversimplified understanding of the backend of lemm.ee This

Am I correct? Or is there another loadbalancer in front of the DB?

Sorry for asking so many questions, but I'm new to system design and trying to learn about practical deployments.

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

That's pretty close, but there are some nuances.

  1. One of the servers is currently exclusively dedicated to handling images (processing, indexing, resizing, uploading to object storage)
  2. One of the servers is only handling Lemmy HTTP requests
  3. One of the servers is handling Lemmy HTTP requests + at the same time also handling Lemmy background tasks (different cleanups, updating the front page rankings, etc)

Additionally, we are not using Docker at all for lemm.ee. Not that I have anything against Docker - I use it regularly in other projects - it just wouldn't provide any advantages for lemm.ee at the moment.

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

Thanks for the clarifications. I now understand the architecture of lemm.ee.

However, by the way you have horizontally scaled things, it had to be done manually. You basically tried to decouple different lemmy functionalities and put them in different servers. It's not as simple as setting a simple env variable as the number of servers.

Also, with this approach i feel like it's possible some servers will be loaded more than others. Eg, server 1 which handles images will be more CPU/RAM-heavy, where as server 2 which handles HTTP requests will be mostly network-heavy. So there will be cases where the scaling is not unform.

Please don't consider this as criticism (i personally just play around with my raspberry pi) but rather as observations.