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
fix: improve localstack test performance #184
Conversation
✅ Deploy Preview for effortless-malabi-1c3e77 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
stack: cloudAssembly.getStackArtifact( | ||
stack.artifactId | ||
) as unknown as cxapi.CloudFormationStackArtifact, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work? What is cloudAssembly
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cloud assembly is what CDK calls the output of a stack synth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Original inspiration: aws/aws-cdk#18667 (comment)
Build failed after 13 minutes. Sure it's an optimization? |
Small WriteupCDK exports two libraries, the Stack synth produces To do this, (copied code from a github issue) we load the assembly output from This worked, but was taking 80+ seconds. Before // synth
const cloudAssembly = await asyncSynth(app);
const sdkProvider = await SdkProvider.withAwsCliCompatibleDefaults({
httpOptions: clientConfig as any,
});
// config hacking...
// @ts-ignore
sdkProvider.sdkOptions = {
// @ts-ignore
...sdkProvider.sdkOptions,
endpoint: clientConfig.endpoint,
s3ForcePathStyle: clientConfig.s3ForcePathStyle,
accessKeyId: clientConfig.credentials.accessKeyId,
secretAccessKey: clientConfig.credentials.secretAccessKey,
credentials: clientConfig.credentials,
};
// convert the aws-cdk-lib/cx-api CloudAssembly into a @aws-cdk/cx-api CloudAssembly
const assembly = new cxapi.CloudAssembly(cloudAssembly.directory);
const stackArtifact = cxapi.CloudFormationStackArtifact.fromManifest(
assembly,
stack.artifactId,
assembly.getStackArtifact(stack.artifactId).manifest
) as cxapi.CloudFormationStackArtifact
// deploy using
await cfn.deployStack({
stack: stackArtifact,
force: true,
}); Deeper DiveWhy did we need to do this?Well... trying to use the output of the stack form Why are the types different?Two different npm packages. Where does the code come form?From the same source. https://github.com/aws/aws-cdk/tree/7eda25625ec1d15fe610097b0456438d6806d9c9/packages/@aws-cdk/cx-api Why are the bundles different?CDK Strips deprecated fields, methods, and classes out for the v2 release of CDK ( The types be coerced After const cloudAssembly = await asyncSynth(app);
const sdkProvider = await SdkProvider.withAwsCliCompatibleDefaults({
httpOptions: clientConfig as any,
});
// @ts-ignore
sdkProvider.sdkOptions = {
// @ts-ignore
...sdkProvider.sdkOptions,
endpoint: clientConfig.endpoint,
s3ForcePathStyle: clientConfig.s3ForcePathStyle,
accessKeyId: clientConfig.credentials.accessKeyId,
secretAccessKey: clientConfig.credentials.secretAccessKey,
credentials: clientConfig.credentials,
};
await cfn.deployStack({
stack: cloudAssembly.getStackArtifact(stack.artifactId) as unknown as cxapi.CloudFormationStackArtifact,
force: true,
}); |
I THINK that jest doesn't like the performance observer and console logs which are now removed. We'll see. Its running faster in general on my machine. |
Looks like the performance improvement is minor on github actions. Locally I see either 240s run on the function.localstack or 180s runs. On localstack it appears I'd say lets push this change and I'll cut a ticket to further improve. Major timing right now looks like:
The delay is likely driving by lambda bundling as we can see stack synth for the event bus tests is closers to 7s |
stack.artifactId, | ||
cloudAssembly.getStackArtifact(stack.artifactId).manifest | ||
) as cxapi.CloudFormationStackArtifact; | ||
|
||
await cfn.deployStack({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the problem that localstack uses CDK 1.x ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, there is no localstack here (except for SDK props hack above). This is all CDK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right but presumably we only do this to meet localstacks expected CDK 1.x input?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, no, cdk is running locally and localstack only sees the cfn. This is all because CDK doesn't support (aka makes it hard as fuck) to synth and deploy programmatically.
Improving the performance of the localstack tests.
Currently seeing 240s to fun the
function.localstack
tests with a 12m build time.Current Improvements:
Simplify the stack deployment logic saw a 1+ minute improvement on function deployment, hoping for 1-3 minute overall improvement.
Write up detailed performance breakdown
Remove the performance measuring code added
tsc + functionless - 50 seconds
Add CDK, bundle, and run serializer - 160 seconds
CdnCompile - 80 secondsDeploy Stack - 30 seconds