My first experience with Lemmy was thinking that the UI was beautiful, and lemmy.ml (the first instance I looked at) was asking people not to join because they already had 1500 users and were struggling to scale.
1500 users just doesn’t seem like much, it seems like the type of load you could handle with a Raspberry Pi in a dusty corner.
Are the Lemmy servers struggling to scale because of the federation process / protocols?
Maybe I underestimate how much compute goes into hosting user generated content? Users generate very little text, but uploading pictures takes more space. Users are generating millions of bytes of content and it’s overloading computers that can handle billions of bytes with ease, what happened? Am I missing something here?
Or maybe the code is just inefficient?
Which brings me to the title’s question: Does Lemmy benefit from using Rust? None of the problems I can imagine are related to code execution speed.
If the federation process and protocols are inefficient, then everything is being built on sand. Popular protocols are hard to change. How often does the HTTP protocol change? Never. The language used for the code doesn’t matter in this case.
If the code is just inefficient, well, inefficient Rust is probably slower than efficient Python or JavaScript. Could the complexity of Rust have pushed the devs towards a simpler but less efficient solution that ends up being slower than garbage collected languages? I’m sure this has happened before, but I don’t know anything about the Lemmy code.
Or, again, maybe I’m just underestimating the amount of compute required to support 1500 users sharing a little bit of text and a few images?
Hi, programming.dev owner here. From what I’ve been seeing it’s a lot of memory issues. We were hitting swap which was causing massive disk io. You can see what happened with the disk io immediately after the upgrade to more memory.
I know at least one reason is being resolved in this PRWe were also having issues with the nginx config. There were some really weird settings that I don’t think were necessary. Finally, the federation is quite busy. So if someone subscribes to events from 10 different servers, we pull in every single event, even upvotes. There’s currently a lot of work being done around this stuff.
I don’t think Rust is the problem. I think it’s just a growth thing. Every platform has growth challenges, things grow in ways that you never expect. You might have thought that it was going to be IO constrained due to the federation, but in reality it’s memory constrained because memory is actually the most expensive thing to have on a server. etc.
So if someone subscribes to events from 10 different servers, we pull in every single event, even upvotes. There’s currently a lot of work being done around this stuff.
You mean like coalescing multiple events into a single message, or…? (I don’t know anything about ActivityPub, so apologies if this is a stupid question!)
correct. I’ve been looking for the thread to try and find it for you, but haven’t been having any luck. People have been discussing exactly that though, but it seems like it could cause some problems with vote faking. Anyway, it is being worked on!
It could be the devs just like programming in Rust. It’s a nice language lol
I know I do. ¯\_(ツ)_/¯
I think the devs openly stated they aren’t backend bods and asked for help optimising the database as a priority. There’s a bit of work going on on github to sort that out I think. Anyone reading this who can optimise postgresql or contribute to a database agnostic retool should probably speak to the devs as I imagine you’d be welcome.
I wish I could help so much but I doubt they’re going to retool into .net haha.
Which is fine. If they wanted to learn Rust and wrote inefficient code, good for them. I appreciate their efforts. Rust can certainly be beaten into shape and perform well enough in the end.
Rust itself or the way the Rust logic is implemented is not the bottleneck. Like most decent web applications the bottleneck is the database and how the decentralized protocols themselves are reconciled there.
Scaling massive amounts of records like Lemmy has been forced to is almost always IO bound at the database level even when a web service is centralized; this is much more difficult in federated architectures. This is why “NoSQL” databases have increased in popularity, but they are also not a magic bullet as there are major ACID trade offs one needs to consider.
NoSQL databases are no silver bullet and the costs of ACID are usually exaggerated (plus most NoSQL databases actually implement ACID anyway). NoSQL databases and SQL databases often have similar performance characteristics since most of the technology is typically the same under the hood.
Plus from my experience as a database consultant: databases are rarely IO bound, NoSQL or SQL unless you have a strange workload. Most time for query execution is usually spent waiting on loads or executing CPU instructions, not waiting on disk IO.
One benefit of using rust for webservers in general is that it’s possible to have a consistently lower latency compared to GCd langues: discord mentions this in their article about migrating to rust from go: https://discord.com/blog/why-discord-is-switching-from-go-to-rust
Another difference between rust and e.g. python is that rust expects you to invest more time to get code that’s runnable in the first place, but likely more well optimized and correct.
In my experience from writing rust, the language pushes you to write more efficient code compared to python because it makes things like copying visible and also because it’s easier to reason about memory usage compared to garbage collection which means that you’re more likely to have a useful model of the performance cost of various things while you’re programming.
It’s possible that a hypothetical lemmy written in python would have allowed the devs to do some big picture optimizations that they haven’t had the time to do yet in the rust version, so for the time being it might be slower than a python alternative.
Rust is likely to catch up though: eventually the rust version will probably also have this optimization while the python version has to resort to make smaller optimizations that the rust version already had in the first version of the code or that you get for free from the language.
I mean, comparing it to Python is kinda unfair as Rust is closer to C and Python is one of the slowest languages out there. There is a whole spectrum of languages between Rust and Python. The final reason was probably that the devs were comfortable enough with Rust.
I would like to point out that this article from Discord could be considered outdated these days. This comparison is using a old version of Go, that in recent years got a optimization on the GC and now would have much lower spikes than those showed in the article
Still, Rust surely will give you a higher performance and lower latency than Python
Its not code that seems to have difficulty scaling, it seems to be user curation and user trust that is being difficult to scale.
The lemmy.ml post that asks people to go elsewhere is still stickied and the first thing it mentions is that they have upgraded the server. So that does suggest that compute scaling is an issue.
It could also be an issue with disk i/o, data port throughput, database performance…
I mean, with all the server issues we’ve seen with the influx of users, it does seem like the code is difficult to scale
At this point I think the bottleneck is largely that every server has needed to upgrade for this wave of the reddit migration.
Pulling this out of my ass, but I think the problem might be in Lemmy using websockets.
I feel like supporting 1500 simultaneous users making a request every 10-20 seconds is easier than keeping 1500 websockets alive.
Irregardless, Lemmy does feel very snappy compared to other websites I’ve had the displeasure of using. Main problem is low robustness in the RPC layer.
They’re gonna move away from we sockets within a couple of weeks, from what I hear
Wait — it uses websockets for each and every user??! That’s just completely insane and of course it will fail to scale! There is zero reason for that, have specific live threads with websockets where it makes sense (though that is only mostly a one-way communication so even there it is an overkill), but for mostly static content it is just insanely inefficient… surely I’m more than fine with that upvote appearing a minute later and not in “real time”!
As I said - I’m pulling this out of my ass. Browser debugging tools don’t support websockets well, but looking at the network log, it seems to start a websocket for every tab.
deleted by creator
I think threads like this one: https://news.ycombinator.com/item?id=28440742 help explain the complexity of performance. There’s considerations from the development process, existing technology, simplicity, and more.
When it comes to architecture I’m not a genius, but I think a lot of how federation works is tough.
Plus, even if you have a perfectly efficient backend it can only handle so much based on the hardware you’re running on. “Struggling to scale” can just mean “struggling to afford better hardware.”
I agree, hearing about scaling issues so early into adoption is concerning. Lemmy advocates say “horizontal scaling is already built in! just add more instances!”, but that doesn’t explain the problem.
It’s all just text! By my guess too, handling text alone a server should easily support a thousand concurrent users, and hundreds of thousands of daily users. A RasPI should handle thousands. I’ve heard the bottleneck is the database? In that case Rust is not to blame, Postgres is.
But my fear is that the data structures are implemented in a trivial way. If you have a good reddit-sized thread with a thousand comments, but you store each comment as a separate database entry, then every pageview will trigger a thousand database lookups! The way I imagined making a reddit clone is that I would store the comments as a flat list with some tree data on top, such that serving a single page with 1000 comments is no different that streaming a 100K text file. I’ll go take a look how Lemmy does it currently once I get the courage!
As an aside, congratulations! This thread was cross posted to Hacker News:
What makes you think that inefficient rust is slower than efficient Python? I mean, sure it could be possible if you are actively trying to make rust slow, but rust is multiple order of magnitude faster than python. If rust was to blame here then I don’t think any language could be fast enough.
Rust is not to blame, but that code that has been written in Rust might be to blame.
The algorithms used have more effect than the language used, and Rust might make using certain algorithms more painful and thus steer programmers towards less efficient algorithms. Using
cloneis often an example of this, it’s a little easier and gets around some borrow checker difficulties. (This is true in general, but I don’t know if this is what has happened with Lemmy.)Look at salvo [diesel] coming it at #200+ on this benchmark1, lots of programming languages have at least one framework that is faster on the microbenchmark. This isn’t especially meaningful, but it does show that, let’s say, a feature rich framework in Rust might end up being slower than a Python framework that’s laser focused on the specific use case.
There’s a catch here, something I read someone mention on Hacker News and I agree. Python is easy when you don’t care about performance; the moment you need to worry about it, all the easiness gets thrown away.
Everything is easy when you don’t care about performance.
Have you ever used py-spy? It’s an excellent profiler for Python code (written in Rust 😉). It can attach to a running process and tell you what line is taking the most time. Seems pretty easy to me. (Which is not to say Python can achieve optimal C speed.)
I don’t think there’s such an easy profiling tool for C or Rust? But I’d be happy to be proven wrong here.
Go solve 20 or 30 Project Euler problems. All of them are solvable in less than a second using Python (or any language). Write your solutions in C or Rust and you will soon see that a naive or brute-force solution in Rust will literally never finish (the heat death of the universe will come first), but a clever and efficient solution in Python takes less than a second.
This is why I say algorithms matter more than language. There’s like 2 or 3 orders of magnitude to be had by choosing the fastest language (which is to say, Rust might be 1000 times faster than Python in some cases), but there’s like 10 or 20 orders of magnitude to be saved using the right algorithms sometimes.
