

Rails 3.2.13 - Performance regressions and major bugs - sephine
http://blog.bugsnag.com/2013/03/20/rails-3-2-13-performance-regressions-major-bugs/

======
jrochkind1
Okay, some of these problems are (unintended) direct side effects of the
security fix bugs.

Like I the one about scopes that effected Github -- github quoted [this
commit]([https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...](https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23))
as introducing the bug, which is the commit meant to address CVE-2013-1854.

So, okay, bugs happen, even with security fixes, I can forgive bugs.

But others of those performance regressions... " handing that task to
Sprockets instead of resolving internally, which seems to be the cause of the
performance issues."

This doesn't sound like the unanticipated side effect of a security fix. This
_sounds_ like an independent change they threw into the same patch release
with four (four!) security patches.

Why is Rails putting security fixes and other non-security-related
enhancements together in the same patch, so you can't get the security fixes
without also getting the possibly buggy new features/refactors? Does Rails
actually do this by policy? Was it a mistake?

Bugs happen, including bugs in security fixes, sure. But it's BECAUSE bugs
will happen that you don't throw unrelated new features or refactors into the
same patch release as a security patch, so the only way to get the security
patch is to risk MORE problems from the other stuff too! Come on!

~~~
timdorr
This is a weird comparison, but they should adopt the same release policies as
Drupal. Security releases are done separate from maintenance releases, even if
they are released at the same time.

That allows you to provide the security releases as a separate patch file so
you can apply individually. You can skip maintenance releases that cause
problems but still keep things secure.

~~~
rst
Here's a pointer to the security fixes in the release as a monkeypatch to
3.2.12, without any of the other cruft:

[https://github.com/discourse/discourse/blob/master/lib/freed...](https://github.com/discourse/discourse/blob/master/lib/freedom_patches/rails_security_fixes.rb)

The discourse folks who threw this together have an app (Rails-based forum
software) that was hit very hard by the performance regressions.

------
sergiotapia
At this point I'm seriously considering dropping Rails as my framework of
choice and reverting back to ASP.Net MVC.

Why?

1\. Security fixes are released very quickly (good thing), but more often then
not they break existing code (bad thing) - and while you _can_ wait for the
next patch to fix those break points, you're left wide open since everybody
can see what was broken and how to exploit it.

2\. I'm not nearly smart enough with Ruby to apply 'band-aids' I read people
write in Rails source code. I just don't have the time and energy to fix code
in the actual framework when I need to be fixing _my_ code.

======

So there you have it; I'm bailing.

It was a fantastic ride, Ruby is a beautiful language, but Rails is just a
clusterfuck (_for me_).

I need stability and predictable behavior. If that means releases every 6
month to 1 year, so be it.

So long and thanks for all the gems.

~~~
eduardordm
I've been running Java and Rails since 2006 in my company (large), we use C#
for a small number of desktop applications.

This will come out harsh, but I'm being honest: If you are not willing to
fix/adapt/improve the framework you are using, you better not be using ASP.NET
also (try a google search on asp.net issues), or any framework at all. In
fact, developing larger more complex software might not even be possible
without adapting frameworks for your specific problems.

That said, our run so far with Rails and Java (we are still using 2.3!!!):

\- We have 38 patches applied to Spring

\- 4 patches in apache santuario.

\- One security patch on Grizzly (glassfish)

\- Rails: One single pull request <https://github.com/rails/arel/pull/174>

~~~
narrator
It's really nice being able to trace into the guts of hibernate, spring, etc
to see what the heck is actually going on and fix it if it's broken. When I
used to do Microsoft stuff, I'd run into bugs in the stack that I couldn't
fix. This was enormously frustrating and time wasting. The typical advice
given out by support was re-install or buy the latest upgrade. There were also
a lot of deliberately imposed architectural limitations to prevent you from
working around lack of "enterprise" features in the basic versions which were
incredibly frustrating and the enterprise version pricing was astronomical.

~~~
JohnBooty
The open-source situation at Microsoft has really improved. Source is
available for a lot of their web stack, contributions are accepted, and there
are some nice open-source frameworks (like Nancy, MIT-licensed, inspired by
Sinatra) that run on IIS or another Owin-compatible server these days.

I generally prefer Ruby-based things myself - this post isn't trying to sway
anybody to the MS side; just wanted to give a bit of credit where it's due and
perhaps a bit of news to those who haven't looked over onto that side of the
fence in a long time.

------
bratsche
I disagree with the final statement of this, that a "security only" release
would have somehow helped the situation. I feel like part of the problem is
that things are being merged into 3-2-stable and nobody is using them because
they're never put into a release.

3.2.11 and 3.2.12 were both security-only releases, and so fixes and patches
that were not security-related have just been piling up for the longest time.

Seems like a "release often" mindset might be better and might ensure that
things are actually being used. Sure, I know someone is going to blast me
saying that bugs like this shouldn't make it into 3-2-stable at all, and since
this is Hacker News so whoever says that knows they're ten times the developer
that everyone on the Rails core team is. But the reality is that bugs make it
into stable branches, and almost nobody is running against the stable branch
(Rails core people are probably mostly running against the 4.0 branch,
everyone else is running against the latest release).

~~~
mnarayan01
Actually 3.2.12 also added some sort of silly (and broken) patch related to
quoting numeric values in ActiveRecord. The primary thing I want out of 3.2.13
is reverting this.

To your more general point, while I don't disagree with your diagnosis of
things piling up in stable, I'm also not a big fan of your proposed solution.
It looks to me like 3-2-stable is getting filled with a lot of stuff that just
should not there; increasing the release frequency is not going to solve this
problem.

------
FuzzyDunlop
I think the only mistake made with this patch release was merging in 250+
commits, ranging from last year to the present day. Maybe that's standard for
such a large project, but it feels like a hell of a lot of tweaks for a minor
release.

As for the rest - I think the issues in January has put Rails in the
spotlight, and while scrutiny is certainly warranted, I think the extra
pressure on the project over the past months to clear this stuff up has had
its consequences.

~~~
yxhuvud
I think the problem is that they do too many patch releases and not enough
minor releases. This could easily have been a minor.

------
1qaz2wsx3edc
296 commits for a security patch is silly; What the shit tenderlove.

~~~
calinet6
Seriously. Usually Rails feels like riding in an Uber, but this release felt
like Crazy Taxi.

------
thinkbohemian
Not happy? Do something about it: try release candidates, report bugs, and
help triage and fix reported bugs.

~~~
foobar2k
I completely agree with this. We (bugsnag) are running on rails 4 beta right
now to help iron out any production issues before that is released.

We didn't, however, realize that "patch" releases also have release
candidates. I'd recommend following the rails blog
(<http://weblog.rubyonrails.org/>) which announces release candidate builds
too.

~~~
thinkbohemian
You can also subscribe to the rails-core mailing list, all betas, RC and full
releases get announced there.

~~~
thibaut_barrere
There's quite a bit more discussions on rails-core apart from RC and releases,
so subscribing to the blog is a good idea if your time is limited :-)

------
ryanSrich
As someone who is relatively new to Rails can someone explain to me why it
seems to update more than anything else I've used?

~~~
davidw
Mostly to give people on forums something to bitch about.

Serious answer: a few months ago, some serious vulnerabilities were found in
Rails. This apparently had a "blood in the water" effect on security people,
who started dissecting the entire thing. Predictably, more vulnerabilities
have emerged and rapidly been fixed.

All in all, it means that things are improving because it's getting a ton of
attention.

~~~
philipDS
This. I think the rapid release cycle of Rails is a good thing, rather than a
bad thing. The past few months, some serious vulnerabilities were found in
Rails, and I guess this made the Rails core team a little anxious.

One might argue that these performance regressions are unacceptable, and they
are. I agree. Still, Rails is relatively young framework and these things
happen. I expect any framework that is widely used will see some serious
vulnerabilities in the next few months/years.

By the way, a good explanation of what these past Rails security issues mean
is explained on patio11's blog ([http://www.kalzumeus.com/2013/01/31/what-the-
rails-security-...](http://www.kalzumeus.com/2013/01/31/what-the-rails-
security-issue-means-for-your-startup/)).

OT: I'm also writing a book on upgrading your Rails 3 app to Rails 4. With
these rapid releases, a lot of things change and it's not always clear what
has changed or what is new. Feel free to check it out at
<http://upgradetorails4.com/>.

------
scottshea
You know when you're already having performance issues on Heroku having a
performance regression is not fun.

~~~
nifoc
How is this

> […] handing that task to Sprockets instead of resolving internally […]

even remotely related to performance issues because of random routing? You're
mixing two issues that have nothing in common.

~~~
josephlord
1) Grandparent has performance problems on Heroku.

2) The Rails release has performance regressions (i.e. in at least some
scenarios is slower).

In situation (1) you don't want to add further slowdown so (2) is a bad thing.

Grandparent doesn't even blame his Heroku performance problems on the routing
issue (although it is a plausible guess). Actually effect of the routing
problem can be significantly worsened if even a subset of requests are slowed
down.

~~~
nifoc
I'm under the impression that the Sprockets regression should not affect you
in production, because your assets are precompiled.

Is that not the case?

~~~
josephlord
To be honest I don't know and I wouldn't have negatively responded to a
comment indicating that or questioning it. However reading the article it
sounds like it is an issue resolving asset paths so may affect you even when
assets are precompiled.

 _Performance Regressions

There are performance regressions in 3.2.13 for both view loading and asset
loading. Rails 3.2.13 changed the way assets paths are resolved, handing that
task to Sprockets instead of resolving internally, which seems to be the cause
of the performance issues._

~~~
fredwu
Actually, the performance degradation to the precompiled assets is minimal -
for a typical production environment it only effects your asset compiling time
as the assets are served statically from your public directory.

------
ChrisInEdmonton
There's been a few people suggesting that, if you are bitten by a bug, you fix
it and submit a pull request. That's a good idea. I did exactly this to a
regression introduced in 3.2.9, complete with a unit test and a pull request
against 3-2-stable and one against master. It took two months to get anyone to
look at it, and while one of the two pull requests has a thumbs-up, it's still
not been merged. Admittedly, this isn't a security issue as far as I can see,
but still.

~~~
steveklabnik
I personally read every single issue and comment filed against rails/rails. I
often don't comment if it's not a part of the codebase I'm not familiar with,
and it's the same with merging.

Can you point me to the specific ones so I can look at them again?

~~~
ChrisInEdmonton
Yeah, tvongaza is correct. Admittedly, it's not a _big_ issue, and perhaps I'm
going about things the wrong way. If you could tell me a better way of getting
this issue fixed, I'd love to hear it. The only other time I tried, it took
more than two years. Luckily, it was pretty easy to monkey-patch our own code
to deal with this, once it broke our live site.

~~~
steveklabnik
Other than tenderlove and (sort of) myself, nobody is paid to work on Rails.
This means that it's an entirely volunteer effort, and people's lives are
busy, so sometimes, tickets take a while to merge. I try to stay on top of it
actively and thing still sometimes slip through the cracks for me. It's not
that you're going about it the wrong way, it's that projects with ~200 open
pulls are slow to merge, sometimes. Sorry it's taking so long with this one.
:/

I'll bump this up in my personal list; I should really learn AR better anyway.

------
renownedmedia
Since when do Rails developers worry about performance?

------
martinced
I'm sure that Rails is great and powers many websites and that many devs loves
it.

I'm also sure that people are working hard to fix these recent security issues
and perfs issues.

But as a non-Rails dev I can tell you one thing: with all the attention that
Rails got lately I'm sure I'll _never_ be learning Ruby / Rails.

I'm into Clojure right now. Next target is Go.

Sadly all these Rails exploits _do_ have a negative effect for Rails: I'm not
saying this to criticize Rails. I'm saying this because I'm honestly 100% sure
I'll never ever be doing anything serious with Rails and I know I'm not the
only one in this case.

So, Rails devs, fix this and fix this rather sooner than later because every
exploit is missed opportunities.

~~~
ldh
I don't write Ruby either right now, but I would suggest you not discount it
as a nice language because of your perceptions of Rails.

