oldmoe 🍉 Profile picture
Aug 24 5 tweets 1 min read Read on X
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)
2. Memory

Ruby is known for being memory hungry, your app processes can consume a lot of memory specially when you use many processes/threads

Quick fixes:
- Use Jemalloc
- A preforked server like Falcon
- A fibered server like Falcon (less memory fragmentation)
3. IO

A lot of your app time is spent on IO, whether the network or any data store you are using.

Quick fixes:
- Use SQLite (via Litestack, eliminate network and lots of Ruby overhead)
- A fibered server like Falcon to increase concurrency
In summary:

- Falcon as your server
- Litestack for data
- Oj for JSON
- Jemalloc
- Yjit

The best part? All these are transparent (or mostly transparent) and they require no changes to your app besides some config params

Configure them once and get a faster & leaner app

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with oldmoe 🍉

oldmoe 🍉 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @oldmoe

Aug 24
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

⬇️
We used background, stateless node.js processes for that purpose, the Ruby process would pickup a backend, send the game state to it for processing and get the results

By using Fibers we did all these requests concurrently and the node.js backend could scale as we needed

⬇️
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(