-
Notifications
You must be signed in to change notification settings - Fork 121
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
Upgrade to any version > 0.18.2 more than doubles CPU usage #209
Comments
Hey sorry about this, I have been working on profiling the library and fixing the hot spots, this PR #217 is the work. The main changes from 0.18.2 to 1.0 are that we are doing more scrubbing/truncation work and the logs no longer are batchable. So I am addressing those two areas. Will update you with what I find. |
Thanks for the update, looks good so far |
@rokob are you using blackfire or what? just curious 👍 great job |
Xdebug and Webgrind |
@rokob Was this was resolved by #217? This comment from that PR indicates that the performance fixes are behind a configuration flag that's disabled by default and doesn't appear to be documented anywhere. Can you provide further details here? |
@elazar I believe the configuration flag is |
So there are a few potential issues that could have been causing performance problems. I fixed all of the ones that I could find. I also reintroduced the ability to send errors in batches instead of as they arise. However, the way we send batched errors is different as we no longer support an api endpoint that accepts a batch of errors. Instead we are using libcurl's multiplexing feature. So you can choose to batch errors with the boolean config parameter So by default a decent chunk of the performance improvements are already part of the current release as they do not change the way requests are sent. However, if you want to try turning on batching you can choose to do so, but note that it may have a positive or negative impact on your performance depending on the actual workload of your app. |
Thanks for your effort on this @rokob we will be testing out |
Going to close this, please re-open or open a new issue if there is still a problem. |
We still experienced a massive performance hit (pretty much unchanged from before - with both batching (50) on and off). I realize that is not super helpful in narrowing down where the problem is. Just got approval for blackfire, so will benchmark the differences and hopefully narrow down where the issue lies. |
I'd like to chime in that I'm also experiencing massive performance issues. I updated to the latest version (1.3.1) and my server load goes up by a factor of 20 or more. It is unusable in a production environment. |
Hi,
Using Rollbar 0.18.2:
We normally see 2-4k requests per min come through our load balancer, which are then served by 2 AWS m1.large instances at ~40-60% CPU utilization
Using Rollbar 1.0.1 or 1.1.1 (tried to upgrade twice):
Our 2 AWS m1.large instances immediately jumped to 90-100% CPU utilization, we then scaled to 5 AWS m1.large instances to support the same amount of traffic at ~40-60% CPU utilization
After experiencing the issue with 1.0.1 I had hoped that this pr: #158 would fix the issue we ran into. That does not appear to be the case.
When upgrading the library, the entirety of our diff is as follows:
There were no additional factors/changes which were introduced at the same time as the Rollbar upgrade.
Please let me know if there is any other information I can provide which would help with tracking down the cause of this issue.
Thanks.
The text was updated successfully, but these errors were encountered: