Upon integrating any performance monitoring tool for your application, you must be observing p95, p99 response times on the dashboards. If you are wondering what do these terms and their values mean, you have come to the right place.
When Nate announced a series of public workshops I
didn’t hesitate and signed up as quickly as possible. Here are my notes from my
experience at the workshop on October 17th.
Hello and welcome to the first OmbuCast by OmbuLabs. In this screencast we’ll
be taking a look at the
derailed_benchmarks gem,
and how you can use it to benchmark your Rails application and find, and
hopefully fix bottlenecks in your code.
When working on a Rails project, you may have seen present? calls on
ActiveRecord relationships. This might feel natural, mostly because present?
exists on all objects via ActiveSupport, so you expect the relationship to respond to it,
but it’s actually not a very good idea. If all we want to do is check if the
scope returns any results from the database, there are better ways than using
present?.
A few weeks ago, I found an interesting project called
Bumbler. If your project uses Bundler,
Bumbler shows you your project’s largest dependencies.
When you find yourself staring at the screen after running
bundle exec rails c, you may want to give this tool a try.
Recently, we started using Skylight in production
for one of our clients’ Rails applications, in an attempt to try to improve the
performance of some of the more critical API endpoints.
Skylight reports on:
Time taken per request
Breakdown of time taken per SQL query
Object allocations per request
I noticed an unusually large amount of allocated objects for one request:
This request would take anywhere from 400ms to 3000ms to respond, which is
WAY too long.