You know that performance is a feature. And a lot of performance problems can be found and fixed during development.
But what about those slowdowns that only show up in production? Do you have to add log messages to every single line of code? That would just slow things down even more! Or do you ship tons of tiny “maybe this fixes it” commits to see what sticks?
You don’t have to ruin your code to analyze it. Instead, try
Trace your running Ruby app
With rbtrace, you can detect performance problems, run code inside another Ruby process, and log method calls without having to add any code. Just add
gem "rbtrace" to your
I learned about rbtrace from Sam Saffron’s amazing post about debugging memory leaks in Ruby (which you should really check out, if you haven’t already).
In that post, Sam used rbtrace to see all of the objects a process used:
This is awesome. But there’s a whole lot more you can do.
What can you do with rbtrace?
Ever wanted to see the SQL statements you’re running in production (and how long they took)?
1 2 3
All method calls that take longer than 2 seconds?
1 2 3 4
Do you want to know every time a certain method gets called?
1 2 3
See which threads your app is running?
1 2 3 4
-e you can run Ruby code inside your server:
1 2 3 4
Yeah, OK, now I’m a little scared. But that’s still very cool. (And only users with permission to mess with the process can rbtrace it, so it’s probably OK).
rbtrace gives you a ton of tools to inspect your Ruby processes in staging and production. You can see how your processes are using (or abusing) memory, trace slow function calls, and even execute Ruby code.
You don’t have to create tons of test commits and log messages to fix problems. You can just hop on to the server, get some data, and hop back out. And even if I’m not totally comfortable using it in production yet, I’m sure it’ll even help out in our test environments.
How about you? What could you use rbtrace for?