Hacker News new | past | comments | ask | show | jobs | submit login

> TL;DR: Mastodon’s Sidekiq deferred execution jobs are the limiting factor for scaling federated traffic in a single-server or small cluster deployment. Sidekiq performance scales poorly under a single process model, and can be limited by database performance in a deployment of the default Dockerized configuration.

Well, that in short explains why Pleroma/Elixir is a much better stack to build this in. You don't need Sidekiq (https://sipsandbits.com/2020/08/07/do-we-need-background-job...) and you aren't stuck with a GIL (Global Interpreter Lock).




Just to note, Pleroma also uses a job queue: Oban. https://hexdocs.pm/oban/Oban.html


Oban is great. (I subscribe to Oban Pro.) It's also seemingly very superior to Sidekiq-like solutions for job management.

But you don't need that. It's certainly a nice-to-have.


> Well, that in short explains why Pleroma/Elixir is a much better stack to build this in

As someone who has extensive experience in both elixir and ruby, and mastodon itself, no this is doesn't.


I read that a Pleroma instance can handle at least 10-50x the traffic of a Mastodon instance running on the same hardware. Based on the reports from other sites that have switched from Ruby to Elixir, this claim rings true. Are you claiming otherwise? I mean, the lack of a GIL alone (thank you, functional language with immutable data!) should give a pretty massive performance improvement


I like Elixir but as of the latest Ruby version, you can use ractors. They aren't bound by the gil


Did not hear of them. Interesting. Also requires a code rewrite to take advantage of them, and still considered very experimental.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: