-
Notifications
You must be signed in to change notification settings - Fork 30
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
Dashboard integration significantly increases Lambda duration #513
Comments
@vbichkovsky Is issue also present when webpack plugin is not used? |
@medikoo yes, it's present, just to lesser degree. I think it may have something to do with the size of the payload sent to the serverless dashboard back-end - it's much bigger when everything is bundled together (in case with webpack). Looks like this data is sent synchronously, hence increasing the duration of lambda. I just ran the version deployed without using webpack, here are the stats:
I guess it can be easily overlooked in such conditions, but in case with a big webpack package (I included whole aws-sdk in my example) the payload in CloudWatch logs is huge and it takes more than 2 seconds (to prepare/log/send it?) The payload I'm referring to looks like this in CloudWatch logs:
|
@vbichkovsky thanks for the details, we will check what could cause that, and get back to you |
@vbichkovsky Data isn't actually sent to the back-end via HTTP request. The dashboard integration works by ingesting logs asynchronously from CloudWatch. So the only operation performed synchronously is preparing that payload to write to the log file. There are a few things we can do to help troubleshoot this. First, if the payload in cloudwatch is huge - please try disabling gzip compression and posting the entire logged result.
That should result in the full json payload being written out. Please then share it here. I suspect that part of this issue is |
There you go, here are uncompressed logs for one invocation, with webpack plugin enabled. |
Here is another one, without the webpack plugin. |
Thanks @vbichkovsky! As I'm sure you've noticed; this appears to be an interesting interaction between Generating an 8MB log file is likely quite time consuming (and also expensive both in terms of CloudWatch costs at $.50/GB ingested and compute time of the lambda invocation itself.) Just to confirm - if there is no error in the invocation, is lambda duration impacted at all? |
No, it's only impacted when there is an error. I think it's stackman, indeed, as it tries to provide context about the error and assumes that runnable code conststs of multiple relatively short lines whereas with webpack (and other bundlers) there is just one huge line of code with all the modules bundled together. |
Enabling Dashboard integration via setting org and app properties in serverless.yml while using webpack packaging and aws-sdk as a runtime dependency, results in significant Lambda runtime duration when an error occurs in the handler.
serverless.yml
I've prepared a sample project in a public repo: https://github.com/vbichkovsky/sls-issue In order to expose a problem, the app has to be deployed and an API Gateway endpoint has to be called.
Installed version
The text was updated successfully, but these errors were encountered: