@r38y 's customer details their performance tuning effort!

We thought this comment to our last blog post really says it all. Congrats everyone on solving a sticky performance issue with New Relic RPM

tikaro said…

I’m @r38y’s client on this job. Here’s what Randy did for my application.

We’re coming out of “throw it at the wall and see what sticks” mode, and entering “okay, we know what we want to do, let’s do it faster” mode. Our six(!) EngineYard slices were running at about 100% app capacity and 120% DB capacity, serving about 2,000 requests per minute. Our queue was growing, and our site was about to go over the handlebars.

Randy implemented partial caching, reducing the DB load per page by about one bazillion inexpensive lookups. We had some idea from httperf what this was going to do for us, but being able to watch NewRelic BEFORE, DURING, and JUST AFTER your deployment is a big confidence-builder.

Sure enough, our request-per-minute threshold went up, our application started serving more requests, and the Dangerous Backlog of Queued Reuests started deflating. Whew!

marketing@newrelic.com'

View posts by .

Interested in writing for New Relic Blog? Send us a pitch!