Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance degradation in Rails App with 9.0.4 (Compared to 1.7.23) #3595

Closed
ylansegal opened this issue Jan 12, 2016 · 4 comments
Closed

Comments

@ylansegal
Copy link

I'm working on upgrading a Rails 4.2 application from jruby-1.7.23 to jruby-9.0.4.0. This is a fairly large app, running on trinidad and using MySQL and MongoDB.

I am opening this ticket as suggested by @headius on IRC (Thanks to @enebo too for helping out).

The first indication of performance issues is our specs take way longer. On 1.7.23 it takes 17:55, on 9.0.4.0 it takes 41:15. Over 4K specs running.

Our unmodified code, running locally on trinidad and hitting a single endpoint (it's a pretty slow one to start with, that involves quite a bit of database activity). The benchmark was conducted with siege, twice on each version (for warmup):

$ siege -c 4 -t30s $URL

For 1.7.23:

Transactions:                 59 hits
Availability:             100.00 %
Elapsed time:              29.05 secs
Data transferred:           0.27 MB
Response time:              1.38 secs
Transaction rate:           2.03 trans/sec
Throughput:             0.01 MB/sec
Concurrency:                2.79
Successful transactions:          59
Failed transactions:               0
Longest transaction:            1.92
Shortest transaction:           0.46

For 9.0.4.0

Transactions:                 45 hits
Availability:             100.00 %
Elapsed time:              29.08 secs
Data transferred:           0.20 MB
Response time:              1.96 secs
Transaction rate:           1.55 trans/sec
Throughput:             0.01 MB/sec
Concurrency:                3.03
Successful transactions:          45
Failed transactions:               0
Longest transaction:            3.32
Shortest transaction:           0.60

As you can see the response time is 42% slower.

If I modify the code so that the controller does nothing (except for before_filters and auth token validation) and returns head :ok, then the performance is quite similar (9.0.4.0 is 6% slower). This would indicate that there is something inside our code.

As suggested by @headius, I tried runnig the same benchmark with profiling in --sample mode. You can see the results for both 1.7.23 and 9.0.4.0 in this gist. I would appreciate some help reading the output: I can't tell from that where I should focus my attention on.

I also profiled the inside of the controller action in 9.0.4.0, but I can't see an obvious bottleneck either. The results are in the same gist.

I appreciate guidance and direction to get to the bottom of this.

Thanks,

@ylansegal
Copy link
Author

The original IRC conversation can be found at http://logs.jruby.org/jruby/2016-01-08

Search for "Ylan" for the correct portion.

@kares
Copy link
Member

kares commented Jan 12, 2016

personally would try profiling and digging with some Java tools to find out where the issue is coming from.
have checked the sample profiles but did not spot anything interesting.

@ylansegal
Copy link
Author

The slowness in spec seems to have been a red herring: Our CI server's configuration is wonky and it was running the 9.0.4.0 build on machines that were slower than the ones running the 1.7.23 builds.

As far as the trinidad performance, we still see the issue in our development machines (about ~25-40% slower for 9.0.4.0) , but I am planning on researching this further.

For now, I will close this issue and re-open if I think appropriate.

Thanks to everyone for their time.

@headius
Copy link
Member

headius commented Jan 16, 2016

@ylansegal Ok great, hopefully you'll see better perf or be able to report more information in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants