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
(aws-lambda-nodejs): slowdown at esbuild bundling #23930
Comments
I'm not noticing any difference @dambaron, the time seems to remain about the same for me. Could you post reproduction info like your nodejsfunction definition, as well as the actual handler file? Thanks |
Hi @peterwoodworth, I won't be able to post the handler itself but the definition goes like this const nodejsFunction = new NodejsFunction(scope, `${lambdaReference.name}Function`, {
depsLockFilePath: join(__dirname, '../yarn.lock'),
runtime: Runtime.NODEJS_18_X,
tracing: Tracing.ACTIVE,
timeout: Duration.seconds(10),
memorySize: 256,
bundling: {
minify: false,
esbuildArgs: {
'--main-fields': 'module,main',
},
externalModules: []
},
// truncated
}) I must add that what we are experiencing happends during a hotswap with a command like:
I'm also attaching to CPU profiles I made for the same command using v What I see is that the bundling seems to work fine but then a very long idle time happens. |
thanks for the additional info, I'm also curious if you notice anything during the idle time you mention if you use the |
Here you are, I cranked the logs all the way up but the outputs are quite similar. |
@peterwoodworth any news after I provided you the logs ? |
@peterwoodworth uping this thread once again |
Thanks for sharing your logs, and sorry for the delay here @dambaron Looking at the logs, it doesn't seem to show anything helpful. I'm curious, at this point in the logs:
does the "very long idle time" you describe occur in Block A, B, or C? Based on everything I'd guess C, is this right? |
Exact @peterwoodworth , the slowdown occurs in block C. I've been able to retrieve the esbuild commands and run them outside the deploy phase and duration is the same inside or outside cdk. What I'm experiencing is awfully close to this (#19021) |
If it's similar, could you check CloudTrail to see if a bunch of duplicate calls are going off? |
@peterwoodworth CloudTrail was not enabled but through an http proxy I was able to determine that I have the same number of requests with roughly the same execution times. The only thing I see now is that a significant amount of time is spent here in the |
Describe the bug
When bumping aws-cdk from
2.55.1
to2.56.1
my team witnessed a significant slowdown during the esbuild bundling. The bundling increased more than 3x. This behavior has been observed all the way up to2.62.2
.Expected Behavior
Bundling time should remain consistent between versions (or decrease).
Current Behavior
Bundling time has been multiplied by 3 only by bumping the aws-cdk version in the package.json.
Reproduction Steps
2.51.1
.2.61.1
.3.Examine synthesis time
In my case:
2.55.1
: 12.02s2.56.1
: 65.07sPossible Solution
No response
Additional Information/Context
package.json
CDK CLI Version
2.56.1
Framework Version
No response
Node.js Version
v18.12.1
OS
Mac OS 13
Language
Typescript
Language Version
4.9.4
Other information
No response
The text was updated successfully, but these errors were encountered: