Cold start and Duration times

[T-Klug]

The first number is durationMs - and the second is initDurationMs

Even with the experimental flag, these numbers are pretty abysmal for cold starts and even durations (due to the flush)

Is the only solution to this writing a delivery mechanism ourselves? What other options exist because this is a big hit on performance.

[purple4reina]

Hey @T-Klug, Thanks for reaching out. Can you share with versions of all our layers you are using, including which runtime you're using? I suspect that most of your added init time is coming from the tracing layer, but I can't know for sure unless I get a bit more info about your setup.

[T-Klug]

Using latest nodeLayerVersion 115 and extensionLayerVersion 65

Using node 20 with the CDK NodeJSFunction construct

[purple4reina]

Thanks @T-Klug. Can you test with just the extension please, and no tracing layer? To do this, you'll set addExtension: true and remove the nodeLayerVersion: 115. If you have any datadog references in your code, or have manually added any handler redirection, please remove it for this test.

Datadog's next-gen extension shouldn't add nearly as much overhead as you're seeing, other customers have reported overhead in the 10s of milliseconds range compared with their base implementation. So, I'd like to confirm that this overhead is not actually coming from the extension, but from the tracer.

[T-Klug]

the type doesn't have addExtension: true and when removing the nodeLayerVersion - the entire handler stops working

We add the lambdas as so

[T-Klug]

After reviewing your documentation on the CDK - that is not the correct way of running it.

[T-Klug]

Marking enableDatadogTracing: false does get us in a bit of a better spot

[T-Klug]

still a 200ms difference though between the 600ms and 800 ms

[T-Klug]

from this we can see before datadog - 600ms
after datadog - 1600ms
with experimental flag - 1250ms
with tracing turned off - 800 ms