A Six-Pronged Rails Performance Philosophy

By Sudara Bullet_white Posted in Plugins Bullet_white Comments Comments

"An ounce of prevention is worth a pound of cure.” ― Benjamin Franklin

Application performance problems can be annoying. With luck, you'll spend an hour or two resolving the problem and get back to your real job: building things.

But what happens when the issues start piling up? What happens when "poor performance" becomes the norm?

When looking at performance issues in aggregate and cross-application, a deeper root cause can appear. This can be tough for a team to identify and even tougher to act upon.

Read More →


Product Update: enhanced zoom, 95th percentiles, trace diffs, and more.

By Derek Bullet_white Comments Comments

Today we're excited to announce the release of our latest Ruby on Rails monitoring agent and a major UI update. This release continues our focus on quickly revealing your path to a faster, more reliable Rails app.

Enhanced zoom

Determining how to make your Rails app faster often involves investigating the opposite: inspecting your app's worst performing controller-actions and their requests. We're working to make this investigation effortless. Just follow your intuition when you see a problem area on a chart:


Click-and-drag on the chart to reveal a list of endpoints we've collected detailed transactions traces for during that period. For context, you'll see a sparkline of each endpoint's response time. Sort by slowest response time or largest memory increase.

Read More →


3 pleasantly surprising PostgreSQL Indexing tricks

By Greg Bullet_white Comments Comments

Most Rails engineers know the basics of database performance. They know that if a query is slow, an index may be the solution. Some know the trade-offs between having and not having an index. Or why an index on a low-cardinality column might not help. But everyone is surprised when I show them a few more advanced indexing techniques. The only response I get is Wow, I didn't know that's possible! In this article, I'll show you 3 techniques that render this kind of response.

Read More →


Rails Performance and the root of all evil

By Sudara Bullet_white Comments Comments

Donald Knuth wrote an often quoted paper in the 70s which is still referenced when talking about performance in web apps today.

Premature optimization is the root of all evil.

In my line of work, it is sometimes invoked as a sort of apology; an excuse for why more time wasn't spent on performance: "This sucks, but at least we didn't.....prematurely optimize!"

My job is to fix performance issues and help other developers write well-performing code, so I'm not a huge fan of this quote. We shouldn't let an out of context quote guide our development strategy, no matter the source!

When things bother me, I like to stop to take a closer look. Here's the full quote:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

I translate this to: "When optimizing, don't get distracted by things that don't matter."

I would never translate this to: "Hold off on optimizing things until it really hurts."

Read More →


Getting down with Stackprof: how we added N+1 query detection to Scout

By Derek Bullet_white Posted in Development Bullet_white Comments Comments

Let's get the confusing part out of the way: we're going to get a little "meta". This post is about using one performance tool (Stackprof) to improve another performance tool (Scout's Rails Agent) so Scout can diagnose a common performance pitfall (N+1 queries).

Did I just put "performance" in a sentence three times? You can see I'm a little obsessed.

There's plenty written about why N+1 queries are bad. Is there anything good about an N+1?

Yes! Finding an N+1 is like finding a $20 bill in your couch. It's a performance-enhancing gift and often an easy fix - assuming you can find the spot in your code that is emitting the query.

...and there-in lies the problem. It is difficult to trace problematic N+1 queries on complex apps running in production back to a line-of-code. In fact, I don't know of a tool today you can run in production that does this. Why is it difficult? Grabbing backtraces is not cheap - you can't call Kernel#caller all willy-nilly in your instrumentation. It means you are left with deadends like this when trying to track down an N+1:

missing n+1

In the above screenshot, each ArDescriptor#find query executes quickly (22 ms), but there are 23(!) queries with the same SQL, adding up to nearly 500 ms.

Now, I don't know about you, but I find this incredibly frustrating. Armed with Stackprof, we set out to see: could we make it performant to find the source of N+1s with Scout?

Read More →


"Scout Does Things Right": Gigmit on using Scout

By Nick Bullet_white Comments Comments

Benjamin Knofe of Gigmit

Benjamin Knofe, CTO of Gigmit, sat down with us to share how they use Scout to improve their performance.

What is Gigmit?

Gigmit is a platform to connect music professionals to one another. Artists get opportunities to play gigs, shows, and festivals all over the world by showcasing their music and applying for gig listings created by promoters.

How big is your userbase?

We support 30,000 artists and 2,500 promoters world-wide. We also offer a suite of tools for all things involved in live event management: booking, merchandise, ticketing, and promotions.

Read More →


Older posts: 1 ... 11 12 13 14 15 ... 70