@sentry/serverless adds ~300ms to function duration

[kostia-official]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

"@sentry/node": "^5.27.4",
"@sentry/serverless": "^5.27.4",

Description

I've noticed that the response time of my functions is slow, added tracing, and noticed that at the end of every invocation my lambda sends POST request to sentry. Here you can see a trace:

It's okay to increase response time for requests with error, but if there is no error, I expect that response would be sent immediately. There is minimal code that I've tested:

import * as Sentry from '@sentry/serverless';

Sentry.AWSLambda.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 1.0
});

export const handler = Sentry.AWSLambda.wrapHandler(
  (event, context, callback) => {
    context.callbackWaitsForEmptyEventLoop = false;

    callback(null, { statusCode: 200 });
  },
  { callbackWaitsForEmptyEventLoop: false, flushTimeout: 2000 }
);

[kostia-official]

There is AWS Lambda Extensions API that can help integrate Sentry without increasing function duration:
https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/

[kostia-official]

Okay, I was able to make it work in a reasonable way:
error -> send the error to sentry
no error -> don't send anything to sentry

I've removed Sentry.AWSLambda.wrapHandler and added to requestHandler flushTimeout:
app.use(Sentry.Handlers.requestHandler({ flushTimeout: 2000 }));

[p0wl]

Would be great to know if there are some efforts regarding creating a lambda extension from someone or if @sentry/serverless is here to stay.

We are using serverless-sentry-lib and can't / won't switch to @serverless/sentry because of issues like this one (#3051), #3049 and #2984

[marshall-lee]

@kozzztya

error -> send the error to sentry
no error -> don't send anything to sentry

Using Sentry this way you won't get tracing events. For each incoming request Sentry captures not only errors but also performance metics.

If you want only to capture errors, you could just skip tracesSampleRate parameter.

Also want to say that using Sentry.AWSLambda.wrapHandler is preferable because it captures more lambda-specific context to the events than a generic requestHandler node middleware.

[marshall-lee]

Unfortunately, the delay caused by flush() cannot be reduced on SDK side. We can't even do flush() in background because there's no "background" in AWS Lambda — the instance is frozen between calls.

I think, the only thing that could probably help to add some concurrency is to write an extension using Extension API. I hope it'll lower the response time but you'll still be billed for the duration of flush() done on the extension side.

[boyney123]

There is AWS Lambda Extensions API that can help integrate Sentry without increasing function duration:
aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview

Is there any more information on this?

I noticed the same across all our lambda functions, an increase of about 300ms. A extension would be great! I notice a lot of other platforms are or have moved to this.

I can't find much about sentry doing this? Unless I'm mistaken?

[TomBeckett]

We're also having this issue and after speaking with Sentry support they seem aware of it. For now we've removed Sentry from all our lambda services. This has cut it down from 400m/s to less than 80m/s!

This needs to be looked into as a matter of priority. This cant be the recommended approach? It also seems like the nodejs variant works fine, so its something in the lambda variant for sure.

[KennyDurand]

Same problem here. A fix would be appreciated!