-
Notifications
You must be signed in to change notification settings - Fork 170
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
Rails 4 Compatible? #45
Comments
We run Makara w/ Rails 4 @ TaskRabbit for our UK app and have average response times under 300ms. We're using mysql, however. Try switching to version 0.2.0.beta10. If that fixes it then I have a likely cause for the issue (#35). |
@mnelson Thanks again for your quick response. Upon further investigation, it appears the issue was traced to the newrelic_rpm gem. A recent upgrade introduced the latency and rolling back corrected the response time. I can confirm that both of our applications are using makara + postgresql on Rails 4 now. 😄 |
Hah! Excellent (for me at least). Do you have any idea why the combination of the new NR gem and makara 0.2.x conflicted? It may be an issue worth noting in the readme or at least in this thread. |
Also, fwiw we're running newrelic_rpm as well (3.6.6.147). |
I do not (yet). I have a support ticket in with them now. I downgraded from 3.7.2 to 3.6.5.130 and all is well. Something likely occurred between there. |
We're having this issue as well. @justindowning has there been any developments from the support ticket submitted to NewRelic? |
Getting this on newrelic (3.9.0.229), is there any work ongoing to address this? Or has there been any investigation into the root cause? |
getting ready to use Makara, any updates on this issue ? are newer versions of the new relic gem solving the issue ? I could not spot anything on the new relic changelog. |
I just confirmed 3.9.4.245 still does not work. |
@trobrock what version of makara? The 0.3.0 rc's might have resolved the problem by removing the initial connection logic. I haven't tested against NR as we're using Skylight now. |
I am using 0.2.2. I will try with 0.3.0 later and report back. |
Awesome, thank you. |
Just confirmed, 0.3.0.rc3 still has the performance issues with the latest newrelic gem. |
That is troublesome. Any report of similar performance issues with skylight and (or) a custom statsd based collection of metrics ? |
I haven't heard of anything else. |
Saw the giant performance warning on homepage that doesn't mention Rails 4 but noticed that this thread seems to only deal with Rails 4. Is the performance hit with makara + newrelic_rpm an issue on Rails 3? (If not, worth noting that on the warning on the homepage). |
I agree with @blaibu : the warning sign is helpful to know there are risks but it's hard to proceed from there with some degree of confidence and several steps of performance testing. In our case (Rails 3.2.19, Ruby 2.1.2 and 1.9.3) we did not spot such big performance issue when testing with a recent New Relic version. |
I am having some performance issues with using the makara gem with Rails 4. After upgrading an application and generating some requests, I notice the response time is much slower. I updated the
database.yml
to use the postgresql adapter instead of the makara-postgresql adapter and normal response times resumed. For example:With makara-postgresql: X-Runtime: 4.144442
WIth postgresql: X-Runtime: 0.755197
I have looked at several different reasons why this could happen, and changing the adapter seems to be the cause here. We do have another application that uses Rails 4 and the makara-postgresql adapter with no known performance reduction. I see that you have compatibility for Active Record 4 (https://github.com/taskrabbit/makara/blob/master/lib/active_record/connection_adapters/makara_postgresql_adapter.rb#L4), though neither the README or the Task Rabbit blog post indicate Rails 4 compatibility.
Any ideas why one application would be adversely affected by the use of the adapter using Rails 4?
The text was updated successfully, but these errors were encountered: