4 ms·

We take performance very seriously, but we can't locate and fix every perf regression on our own. If you can give us metrics and repro code, we can work to fix

We take performance very seriously, but we can't locate and fix every perf regression on our own. If you can give us metrics and repro code, we can work to fix the issues.

lukeholder 13y ago
Hey tenderlove, just wanted to say thanks for all you do for ruby and rails. Your a legend mate.
wbharding 13y ago
Thanks Aaron. I imagine I'll probably spend Thanksgiving weekend trying to dig further into what is newly slow on our 3.2.15. The trick with pinpointing a cause is that when I look at the data NR provides, every partial rendered and every action called is slower than it had been previously. Combined with the immensity of our codebase, it's going to be time-consuming to put a finger on a single repro-able cause. But we'll do our best to isolate and report back. FWIW, have you guys ever considered creating a performance suite test app? With such sparse Google results around Rails performance changes over time, it could be useful to compare the performance of Rails versions on an apples-to-apples basis if we could see how the performance of the test app changed over Rails versions. If we're lucky, it might even catch some of the performance regressions that have happened in the dot releases previously. Even if not, it would at least demonstrate that performance is an important consideration in Rails' evolution. I'd sleep better knowing that. Maybe take a popular mid-sized framework like Spree and see how it performs on 3.0, 3.1, 3.2, etc.?
- sams99 13y ago
  If you send me a flamegraph using ?pp=flamegraph_embed I can help you figure out why it got slow. I am actively working on getting a long term perf benchmark using the Discourse bench. Server is already provisioned by ninefold. see my talk (towards the end) http://www.youtube.com/watch?v=LWyEWUD-ztQ http://www.youtube.com/watch?v=LWyEWUD-ztQ
  - psycr 13y ago
    Thanks for building that Sam, we use it all the time and it's proven invaluable.
  - gary4gar 13y ago
    You are doing god's work with Discourse & improving rails/ruby to support 50/ms response/per request. Thank you!
- joerichsen 13y ago
  We have a setup that is fairly similar to yours (large Rails 3.2.15 app, Passenger, New Relic) and we recently experienced the same as you did - just in the opposite direction! What happened is that average response time fell from 415ms to 255ms and across the board everything was faster. This Friday I upgraded ruby on our servers from 1.9.3-p327 to 1.9.3-p448 and that triggered the speedup. Ruby was installed using rbenv/ruby-build and my guess is that the new version was compiled using compiler optimization flags whereas the old one for some reason was not. Might be worth investigating :-)
  - wbharding 13y ago
    We didn't change our Ruby version. We changed as little as possible overall to make the comparison "apples-to-apples." Getting a performance increase during an upgrade would be a highly welcomed change in our world.
    - krisdol 13y ago
      I'm not suggesting that you upgrade to 2.0, or anything drastic, but does this mean you don't install the security updates? Build 448 included important OpenSSL fixes, and no functional changes or deprecations occur during these minor upgrades.
      - kawsper 13y ago
        You should upgrade to build 484 because of this: https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-in-floating-point-parsing-cve-2013-4164/ https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i...
tkellogg 13y ago
2x is a pretty serious regression. I'm really not sure how that could be overlooked. doesn't rails do performance tests as part of their regression suite?

We take performance very seriously, but we can't locate and fix every perf regression on our own. If you can give us metrics and repro code, we can work to fix the issues.

lukeholder 13y ago

Hey tenderlove, just wanted to say thanks for all you do for ruby and rails. Your a legend mate.

wbharding 13y ago

Thanks Aaron. I imagine I'll probably spend Thanksgiving weekend trying to dig further into what is newly slow on our 3.2.15. The trick with pinpointing a cause is that when I look at the data NR provides, every partial rendered and every action called is slower than it had been previously. Combined with the immensity of our codebase, it's going to be time-consuming to put a finger on a single repro-able cause. But we'll do our best to isolate and report back. FWIW, have you guys ever considered creating a performance suite test app? With such sparse Google results around Rails performance changes over time, it could be useful to compare the performance of Rails versions on an apples-to-apples basis if we could see how the performance of the test app changed over Rails versions. If we're lucky, it might even catch some of the performance regressions that have happened in the dot releases previously. Even if not, it would at least demonstrate that performance is an important consideration in Rails' evolution. I'd sleep better knowing that. Maybe take a popular mid-sized framework like Spree and see how it performs on 3.0, 3.1, 3.2, etc.?

sams99 13y ago
If you send me a flamegraph using ?pp=flamegraph_embed I can help you figure out why it got slow. I am actively working on getting a long term perf benchmark using the Discourse bench. Server is already provisioned by ninefold. see my talk (towards the end) http://www.youtube.com/watch?v=LWyEWUD-ztQ http://www.youtube.com/watch?v=LWyEWUD-ztQ
- psycr 13y ago
  Thanks for building that Sam, we use it all the time and it's proven invaluable.
- gary4gar 13y ago
  You are doing god's work with Discourse & improving rails/ruby to support 50/ms response/per request. Thank you!
joerichsen 13y ago
We have a setup that is fairly similar to yours (large Rails 3.2.15 app, Passenger, New Relic) and we recently experienced the same as you did - just in the opposite direction! What happened is that average response time fell from 415ms to 255ms and across the board everything was faster. This Friday I upgraded ruby on our servers from 1.9.3-p327 to 1.9.3-p448 and that triggered the speedup. Ruby was installed using rbenv/ruby-build and my guess is that the new version was compiled using compiler optimization flags whereas the old one for some reason was not. Might be worth investigating :-)
- wbharding 13y ago
  We didn't change our Ruby version. We changed as little as possible overall to make the comparison "apples-to-apples." Getting a performance increase during an upgrade would be a highly welcomed change in our world.
  - krisdol 13y ago
    I'm not suggesting that you upgrade to 2.0, or anything drastic, but does this mean you don't install the security updates? Build 448 included important OpenSSL fixes, and no functional changes or deprecations occur during these minor upgrades.
    - kawsper 13y ago
      You should upgrade to build 484 because of this: https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-in-floating-point-parsing-cve-2013-4164/ https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i...

tkellogg 13y ago

2x is a pretty serious regression. I'm really not sure how that could be overlooked. doesn't rails do performance tests as part of their regression suite?