http lag/wait from Sentry SDK on Laravel on every API call

[amitkoth]

We use Tideways to log performance/stats for our Laravel and PHP stack - which we use to run our REST API.

We've noticed this large issue on all API calls - they are all blocked by Sentry/http waits:

How do we make this SDK non-blocking, async and completely de-coupled from our Laravel codebase? We really don't need errors logged to Sentry in real-time - they can wait a little bit before they push from our EC2 instances into Sentry.

We're very concerned about this because:

1. If Sentry is down - we go down as well, probably
2. If Sentry is slow in responses, etc. - we suffer a backlog of requests that are served slowly and eventually, traffic surges could cause a crash on our side.

I'm open to switching out entirely to another collector/method instead of the PHP SDK. Our aim is to fully de-couple our main codebase from Sentry.

[stayallive]

The best way at the moment is to deploy Relay on the same machine (or inside your network) and let your app send it's events to Relay which will relay it to sentry.io. The communication with the relay instance is near instant (single digit ms) if it's deployed on the same machine or within the same private network.

[stayallive]

On another note, since it's not clear from your description. Unless you are using performance tracing there should not be a request to Sentry for every single request to your app unless you are "abusing" Sentry for logs or there are errors on every request to your app (which is probably another issue).

[amitkoth]

We have no interest in 'abusing' Sentry for logs, so a little more civility in expression would be nice!

We did discover performance traces were on, so switching that off soon.

[stayallive]

It was not meant as a snark at all. My apologies that it came across like that! I am here to help not to pick a fight I was trying to gather what might be causing the problems you are seeing so that I can provide some info or options to explore.

Disabling performance tracing will of course resolve the issue for the most part.

Deploying Relay would still be a good option to ensure that in the event Sentry is unreachable your app might block for longer potentially causing the issues you outlined above when there are errors to sent or when you want to use performance tracing in the future.

[amitkoth]

No worries, got it - we will look into https://docs.sentry.io/product/relay/getting-started/

[Jean85]

Another possible solution could be writing your own transport for the SDK; that would be better compared to Relay only if you could do it locally, or if the transport would implement some kind of deferring, like implement some sort of in-memory spooling.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[nnikolay]

Hi, we have similar issues right now. How can I write my own transport for the SDK? Is there a docu for that? I would like to log everything in a log file on the server and then send it to sentry over fluentbit.
Can you help me here?

[cleptric]

You can create your own HTTP client that implements HttpClientInterface and set it via the http_client option.

[nnikolay]

Is there an existing example available? Additionally, can I use it to write the payload into a logfile?

[cleptric]

No, this is something we do not support officially, so you're on your own.

[nnikolay]

What options do I have to make the request in an async way, so it is not blocking our php process? We use performance and profiling. We have a Symfony project and use sentry for Symfony.