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

Add buffering functionality #196

Closed
and-megan opened this issue Jun 2, 2017 · 5 comments
Closed

Add buffering functionality #196

and-megan opened this issue Jun 2, 2017 · 5 comments
Assignees
Labels
Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component.
Milestone

Comments

@and-megan
Copy link
Contributor

The previous version of rollbar-php (0.18.2) would batch send messages. This version sends messages when they are received. In the case of a severe error, many messages will be logged one after another. Is there any plan to restore the batched messages?

@coryvirok
Copy link
Contributor

Buffering is a good idea. We have this implemented in some of the other SDKs but it's all client-side. We aren't planning on supporting the batch endpoint on the server-side any longer. However, we can support buffering up a configurable # of messages and a maximum amount of time to buffer in the SDK.

If you just want the ability to send data in batches, I would recommend looking at the rollbar-agent to handle this. That's going to be the most performant method and will not require any SDK changes.

@coryvirok coryvirok added the Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component. label Jun 7, 2017
@rokob rokob added this to the v1.4.0 milestone Jun 19, 2017
@unix1
Copy link
Contributor

unix1 commented Jun 21, 2017

Hello @and-megan @coryvirok - thank you for helping. Just to be explicit in changes from 0.x to 1.x:

In 0.x branch:

  • events were sent using register_shutdown_function callback function which executes after php has completed processing and before the process is shut down
  • events were batched by default so only 1 HTTP connection was required to send many (up to configured number of) events

In 1.x branch:

  • events are sent inline as they occur during the execution of the script
  • events are no longer batched (and batching is being deprecated), so for n events n separate curl HTTP calls will be made to rollbar's serice

I'm wondering if I'm missing anything because these 2 changes seem counter-intuitive from the performance perspective, also noting that Rollbar status page reports that average api.rollbar.com response time is >500ms with common spikes up to 1s and higher. Buffering on its own wouldn't address the above 2 issues.

During the normal operation, when we log low number of debug/info/warning/error/critical events, this would still have significant impact on our application performance. But worse, during times when we are experiencing problems and send more events than normal, we could end up compounding effects of an already degraded performance.

Am I missing something, or is there a plan to address this outside of using the rollbar agent? Thank you!

@coryvirok
Copy link
Contributor

Thanks for the feedback! I defer to @rokob on the technical parts.

@ArturMoczulski ArturMoczulski self-assigned this Jun 30, 2017
@rokob rokob modified the milestones: v1.4.0, v1.3.0 Jul 3, 2017
@rokob rokob assigned rokob and unassigned ArturMoczulski Jul 7, 2017
@rokob
Copy link
Contributor

rokob commented Jul 7, 2017

I basically did this in #217 as part of the work on performance, I will update you with the details once that is finalized.

@unix1
Copy link
Contributor

unix1 commented Jul 7, 2017

Excellent! Thank you for following up.

@rokob rokob closed this as completed Jul 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement Changes that add to, improve upon, enhance, or extend the existing component.
Projects
None yet
Development

No branches or pull requests

5 participants