search

BetterErrors / better_errors

Better error page for Rack apps
MIT License
6.87k stars 436 forks source link

Significant slowdown with Sprockets #157

Closed virusman closed 11 years ago

virusman commented 11 years ago

Our project became very slow (4 sec. per request, spending mainly in javascript_include_tag) recently, and it turned out that it's caused by better_errors with binding_of_caller. If I disable either of them, the problem disappears. I'm not sure where to start looking, so just posting it here in case anyone else is experiencing similar problems. Ruby 2.0.0 (same on 1.9.3), Rails 3.2.13, Sprockets 2.2.2, better_errors 0.8.0, binding_of_caller 0.7.1

haileys commented 11 years ago

Try downgrading to Rails 3.2.12

virusman commented 11 years ago

Thanks, this fixed our problem! :)

jdickey commented 11 years ago

Uhhh… @virusman, that got your performance back to previous levels, but downgrading to a known-vulnerable version of Rails isn't something that I'd want to deploy, or close a bug until I understood its cause has been fixed. Is there anything that your Script code is doing that's more than usually time-intensive? I had a project a while back where the previous guy had thought dynamically generating JavaScript would be "a cool thing". A performant thing, not so much...

@charliesome, any idea what the interaction that he's seeing between Rails 3.2.13 and BE 0.8.0 might be? Has anyone else been able to reproduce a similar problem moving between 3.2.12 and 3.2.13? I didn't notice anything like a potential duplicate bug filed, but this isn't the only communication people have. :-)

Great work in general on BE, by the way; I don't mean to sound negative at all. I just get frosted when people take cavalier attitudes towards security, but then I had to rebuild five systems from bare metal after the YAML Security Follies of 2013… :-1:

virusman commented 11 years ago

@jdickey of course I didn't just downgrade to 3.2.12, instead I used this monkeypatch: http://stackoverflow.com/a/15520932 No, we don't do anything unusual, although we have about 30-40 coffeescript files. The real culprit is Rails 3.2.13 (afaik a bug in Sprockets really, that got exposed after part of the Rails code was removed in 3.2.13). It generates a lot of FileNotFound exceptions that get caught somewhere in Rails, and better_errors slows things down even more because it gets bindings for every exception. See https://github.com/rails/rails/issues/9803 for more info. Patching the Rails bug fixed the issue for us. Applications generally don't throw lots of exceptions, so better_errors and binding_of_caller don't cause any significant performance hits in normal circumstances. Thanks for drawing my attention, now this may be more helpful than my previous post if someone comes here with a similar problem.

jdickey commented 11 years ago

@virusman Sorry; didn't mean to be insulting. Add a team of two doing the work of 6, an exuberantly exasperated CEO-in-toddler-mode asking 'Is it done yet?', five potentially penetrated systems of which one is known to need bare-metal rebuild, excess caffeine and anything but excess sleep and… we've all been there.

This patch looks Very Useful; trying it now. Thanks!