Takeaways
When optimizing your application, look beyond the code in your search for performance problems. Sometimes an unoptimized application running on a properly configured software stack will perform better than the thoroughly optimized one in a poorly configured stack.
This chapter has expored several items you need to think about when deploying your Ruby application:
-
Restart your long-running processes when they grow too large in memory. A freshly started application runs faster because the GC has fewer objects to collect.
-
Run heavy tasks in an isolated forked environment. This way the forked process will give back to the operating system all the memory allocated during its execution.
-
Do out-of-band garbage collection if you use Ruby version 2.0 and lower, and your application has idle time. This reduces GC stop-the-world time when your code is actually doing its job.
-
Tune up your database and any other software for optimal performance. Popular PostgreSQL database has over-conservative defaults that are harmful for performance.
-
Review your deployment stack and identify possible sources of slowdowns. If in doubt what to improve in your infrastructure first, buy more memory.
Remember, this list is not exhaustive. Take it as a hint, a starting point, rather than official advice. Forget your Ruby code for a moment, and take a fresh look at how and where it runs. You’ll be surprised by the slowdowns you’ll find.
So we’ve talked about tuning your Ruby program and the software it uses for optimal performance. But so far we’ve ignored the elephant in the room. The Ruby interpreter itself is the most important piece of software that your program runs on. And it needs performance tuning too. That’s what we’ll talk about in the next chapter.