Twitter and Mastodon, and Why Mastodon instances are difficult to scale
-
4 key differences between Twitter and Mastodon | Opensource.com
Social media is not always sociable, and sometimes we need a sufficient impetus to change what we do and what we read. I began using Twitter as a replacement for my RSS reader in 2008, which revolutionized how I read and learned up to that point. Tweets from educators and free and open source (FOSS) advocates worldwide kept me informed and engaged in a learning network that was without equal. That's changed over the past half dozen years, and recently a change in ownership and the shaping of what I read was driven more by an algorithm than by my personal interests and choices. During a yearly meetup of correspondents and editors of Opensource.com a few years ago, Seth Kenlon suggested giving Mastodon a try. I joined Fosstodon in 2019. Fosstodon is a Mastodon instance for a community of like-minded people who enjoy free and open source software.
-
Why Mastodon instances are difficult to scale - Lukáš Zapletal
Mastodon, the free, open-source social network server based on ActivityPub is written in Ruby on Rails and the network is experiencing influx of new users. Mastodon administrators are finding how difficult and costly is to scale Ruby on Rails applications the hard way. I’ve spent a deacde working on a large Ruby on Rails project, much larger than Mastodon. Let me quickly describe what is going on. Disclaimer: This post is solely based on my experience with scaling other Ruby on Rails applications, take this with a grain of salt. Also, I’d appreciate comments at @lukas@zapletalovi.com.
People often think that Ruby on Rails is slow because Ruby is slow, according to various benchmarks and shootouts. Well, while Ruby is not fast at all, it is not the primary reason why that is. See, most web applications, including Mastodon, do not perform CPU-intensive tasks. Most of the time, CPU is actually waiting for data to be read or written from network (client, database, redis) or disk (cache). Even if you upgrade to the most recent Ruby 3.2, which is the fastest of all Ruby versions, it won’t help at all.
Backend software these days need to respond to many of HTTP requests, when a service is under load we are speaking about hundreds or even thousands of requests per second. A single process (instance of software running on an operating system) with naive implementation can handle as much as one request. To be able to handle more, requests must be dealt concurrently, which is a very complex topic but let’s keep in simple. The solution is to create multiple execution threads that can run concurrently on the program level and ideally in parallel on the operating system level to utilize as much CPU resources available.