Is your Ruby web app slow?

Is your Ruby web application slow? That's not unusual. It's part of the bargain you made when you chose Ruby for your web application - you would develop and deploy faster, at the cost of performance. After a while, the features and dependencies started piling on top of each other, and now here you are.

It Doesn't Have To Be Like This

Ruby web applications don't have to be slow, and you don't have to do backflips or refactor your entire application into service objects and microservices to do it. Four of the largest Rails applications in the world are all monolithic Rails applications and they all have response times of less than 100 milliseconds on average - Github, Shopify, Basecamp and Cookpad. Frequently, squeezing more performance out of your application ends up being a simple one-line change. Performance optimization is about measurement and experience more than execution, which is why employing a battle-tested expert like me can save you and your team weeks of banging your head against the wall and blind, premature optimization.

Or maybe you're worried about resource usage - your Ruby app's memory usage looks like a leaky sieve and you're crushing your memory limits. I've showed my clients how to halve memory usage and plug leaky apps.

Worried about scaling to some anticipated future demand? Not sure if your application could hand triple or even ten times the traffic you get right now? I can find the potential bottlenecks to scaling your app.

If your site's performance isn't up to par, your first reflex may be to throw more resources at it. More dynos, more database read replicas, bigger caches. But, now you're drowning in server costs. If you're spending more per month on your application than you have requests-per-minute, you're overspending. Even if you're spending less than that, you could almost certainly be spending even less. It's better to scale smart than to scale blind. That's where I come in - I've helped my clients slash their server costs by up to five figures - per month.

What You'll Get

You'll give me access to your performance metric provider, such as New Relic, Skylight or Scout, and any other server metrics. I'll also need read (not write) access to your source code. We'll discuss your particular performance needs - need a tuneup for the frontend or backend (or both)? Do you have memory issues? Are a few particular workers or controller actions cramping your style?

Next, I'll dive in to your application to see where improvements can be made. Often, these improvements take the form of config changes or one-line changes which can be implemented the same-day. I've saved companies hundreds of thousands of dollars per year by changing a few environment variables or introducing them to a simple tool or Rubygem they've never heard of before.

After a couple of weeks, you'll receive a long-term performance plan, which will contain a dozen or more recommendations for improving the scalability, cost-effectiveness and performance of your Ruby web application. I'll also identify common themes and problems I stumbled upon and tell you what performance skills your team needs to work on improving. We'll have a follow-up call to discuss any questions and comments you might have.

Finally, you and your entire team will get access to my Complete Guide to Rails Performance. If you're getting stuck on any of the recommendations in the report, you can probably find out how to get past it by reading about it in the CGRP. The Complete Guide also is a great way to improve the performance skills of your whole team.

What's a Tune look like?

Previously, we did a Tune for WikiEdu, an opensource project of the Wikimedia Foundation. Since it's an open source project, they were fine with us sharing the Tune report for the whole world to see. You can view it here.

Get Speedshop Tune

Projects begin at $16,000 USD, and usually take 2-4 weeks to deliver.

Email us and get Tune now!

Testimonials

Who's this?