oldmoe 🍉 Profile picture
Xoogler, Rubyist, SQLitist
Sep 7 6 tweets 2 min read
Takes 12 modern cores to do 50K requests per second? How about 58K cores (over 15% more) on my 3 year old 8 core laptop (33% less cores)?

How'd I get it so much faster? Easy, I used Ruby!

I used 8 threads for wrk instead of 12 coz my 8 cores, had I had 12, it would do better
Image Here is the code snippet, even simpler than the JS one Image
Sep 4 7 tweets 2 min read
Every now and then someone from the Rails sphere would make a statement about performance (1/2 req/core/second as the norm 🤦) or (15K reqs from a mega machine) that would sound ridiculous to outsiders who start speaking about how slow Ruby is and delusional are Ruby devs

1/n
Ruby is not slow, in the sense that for building web apps it is in the same league as PHP, Python and similar interpreted languages.

You can build really fast web apps in Ruby, microsecond request latencies, and the toolbox has vast options to help you achieve that

2/n
Aug 30 7 tweets 2 min read
Having worked with a lot of budding developers, I have found 3 learning assignments in particular to be eye opening, both for them and myself

When you are new, many things seem just too hard, but when you build even one of them, u gain knowledge & confidence to do a lot more

⬇️ 1. Build a web server
An actual http 1.1 web server that responds to get, post, put & delete.

Then make it concurrent, threads, forking etc.

Then run rack apps (in the context of Ruby)

You will have a much deeper understanding of web development and web frameworks after.

⬇️
Aug 24 5 tweets 2 min read
In 2014, I had two Ruby apps with over 1M MAUs combined, both were hosted on a single server that cost us ~$75.

It was composed of. Multiple Ruby processes running Sinatra, processing requests in fibers, and each process connects to a BerkeleyDB shard (with fixed hashing)

⬇️ Each BDB shard had data belonging to a set of users, shards can be combined or split, up to 256 of them. Each process had exclusive access to a single shard.

Since this was running web games, we had to have validation logic running on the server replicating the game logic

⬇️
Aug 24 5 tweets 1 min read
A typical Ruby/Rails web app performance is usually limited by one of the following (depending on usage patterns):

1. Compute
2. Memory
3. IO (network & disk)

The good thing is, you can ease these without having to touch your application code.

Read on ⬇️ 1. Compute

It's everywhere, even db ops can be compute intensive. Though Ruby itself is usually the culprit, specially if there is a lot of logic or template/json rendering

Quick fixes:

- Enable Yjit
- Oj gem for JSON
- A fibered server like Falcon (less context switching)