10 tips to boost up performance of your Ruby on Rails application

82 views
Skip to first unread message

Mehreen

unread,
Dec 4, 2014, 6:47:59 AM12/4/14
to rubyonra...@googlegroups.com
Hello guys!

I found a guideline which will help to boost up performance of your Ruby on Rails application. You should check this out.

Dante Elrik

unread,
Dec 10, 2014, 12:44:31 PM12/10/14
to rubyonra...@googlegroups.com
Mehreen wrote in post #1163991:
> Hello guys!
>
> I found a guideline which will help to boost up performance of your Ruby
> on
> Rails application
>
<http://www.nascenia.com/10-tips-to-boost-up-performance-of-your-ruby-on-rails-application/>.
> You should check this out.

I'd like to! Link is dead.

Regards,
Dante Elrik
Founder, CloudShopper

--
Posted via http://www.ruby-forum.com/.

Colin Law

unread,
Dec 10, 2014, 3:51:02 PM12/10/14
to rubyonra...@googlegroups.com
On 10 December 2014 at 17:43, Dante Elrik <li...@ruby-forum.com> wrote:
> Mehreen wrote in post #1163991:
>> Hello guys!
>>
>> I found a guideline which will help to boost up performance of your Ruby
>> on
>> Rails application
>>
> <http://www.nascenia.com/10-tips-to-boost-up-performance-of-your-ruby-on-rails-application/>.
>> You should check this out.
>
> I'd like to! Link is dead.

It works for me. Some of the suggestions are way out of date though,
being written in 2011!

Colin

Josh Jordan

unread,
Dec 11, 2014, 10:20:02 AM12/11/14
to rubyonra...@googlegroups.com
While some of the advice here is good, it represents a very confused view of performance optimization. For instance, #2 is just plain bad advice for performance (but good for modularity) - partial rendering has a ton of overhead in Rails. #3 doesn't speak to performance at all. DRY (#4) is not a performance principle. I stopped when the author repeated #4.

Jason Fleetwood-Boldt

unread,
Dec 11, 2014, 10:46:23 AM12/11/14
to rubyonra...@googlegroups.com
Don’t repeat yourself. Don’t repeat yourself. 

Yea I agree that article is a little cursory. Each one of those 10 bullet points could be an entire blog post itself. Also it doesn’t even mention avoiding n+1 queries, which I think is absolutely essential for ever new Rails dev to learn up-front.

I agree that some up-front stuff is important, like: CDNs, properly using the asset pipeline (compressing & Gzipping, moving to a CDN, etc), indexes on the fields you search against. However, in a company with a high-traffic website and investors who want a return on their money, it’s all about cost-benefit. So you need to think about the payoff for some of your efforts. 

For example, in my experience spriting your images actually costs a lot of developer time with very little payoff when it comes to browser performance. (I’m thinking in the scenario where you might have fewer than 10 images on any given page. If you have hundreds of 25x25 images spriting makes a lot more sense.)

If you do the essentials up-front (listed above), the best strategy for optimization is to use a tool like New Relic to identify your bottlenecks and then optimize anything slow bit-by-bit. It’s tedious but you get a better result in the long run. 

-Jason




--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/5261a95e-ff88-42f2-a020-f443932d1a9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

----

Jason Fleetwood-Boldt

All material © Jason Fleetwood-Boldt 2014. Public conversations may be turned into blog posts (original poster information will be made anonymous). Email ja...@datatravels.com with questions/concerns about this.

Reply all
Reply to author
Forward
0 new messages