- Newest
- Most votes
- Most comments
Provisioned Concurrency helps mitigate cold starts by keeping a set of initialized execution environments ready to handle incoming requests. However, in your case, the initial delay seems to be related to the time required to mount the Elastic File System (EFS) and populate the file cache, rather than a cold start issue.
When the Lambda function needs to read files from the EFS for the first time or after a prolonged period of inactivity, it has to establish a connection to the EFS and load the required file data into the cache. This process can be time-consuming, especially if the files are large or if there is higher latency in accessing the EFS.
Provisioned Concurrency alone may not be sufficient to address this issue because it doesn't affect the time required for mounting the EFS and populating the file cache during the initial invocation.
The subsequent invocations are faster (around 10 seconds) because the EFS is already mounted, and the necessary files are cached in memory, allowing for quicker access.
So, while Provisioned Concurrency can help reduce cold starts, it doesn't directly address the delay caused by the initial EFS mounting and file caching process, which seems to be the root cause of the slow first API call in your case.
Try reading a file in the initialization code. This way you will pre-warm the EFS access during function deployment and not in the first execution.
It could be that your API Gateway(?) call is not using the provisioned Lambda. If you have logging enable, you can check from CloudWatch log group for INIT_START
Do ensure that your API call and provisioned are referring to the same version.
Yes, I am using an API gateway, and I set it to use the versioned lambda before deploying. But it's still slow, the loading process from EFS seems to take a long time. Thank you for answer.
Relevant content
- asked 2 years ago
- asked 9 months ago
AWS OFFICIALUpdated 4 months ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Thanks for the advice. I opened the file outside the handler function, read the file a little, and did not close it. The first function call time has been reduced about 3 seconds. Maybe if I read more, I could save more time.
I inserted the code to copy file from EFS to temporary storage in the init code area. So the handler function read the file from the emphemeral(/tmp/) storage and was able to achieve very fast speed.
There is a lot of work to be done in the static code area, such as transferring and decompressing files. I set provisioned concurrency, so I was able to avoid init in the actual API call.
Thank you again for giving me inspiration and solutions to my problems.