bugsnag-php: BugSnag lib is a performance bottleneck
The Client can be very detrimental to performance because it tries to report the error within the same request cycle. This means that if I have an innocuous error, visitors to my site will suffer from delayed page load times – until the error is reported to BugSnag via curl.
In the best case scenario, this delay is equivalent to the time required to aggregate and report the errors to the BugSnag service. In the worse cases, the BugSnag service can have high latency but still be fast, or have low latency but be slow to respond, or be down altogether in which case the page won’t render to the visitors until the BugSnag curl request times out.
Another direct implication is that offline testing is totally messed up because every request must time out before continuing.
I am unable to justify putting this in my production code at the moment. Would have been nice if BugSnag provided support for syslog so this could be done out of band.
Maybe you could check for pcntl_fork support and leverage that for curl_exec?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 19 (12 by maintainers)
So, using the 2nd option is definitely the way to go, because you get to use all the library features, then just delay the actual http transport part.
Actually, the only method on the guzzle client interface you need to implement is the
postmethod, which we call here: https://github.com/bugsnag/bugsnag-php/blob/master/src/HttpClient.php#L158.Just stub out all the methods of https://github.com/guzzle/guzzle/blob/5.3/src/ClientInterface.php or https://github.com/guzzle/guzzle/blob/master/src/ClientInterface.php, whichever you have installed (you can find out by running
composer show -i), then just implement thepostmethod, to send the json data, and URL to your queue, so you can handle it as you want.We’ve fixed the curl handing issue now.