Lambda warmup not waming up the function properly

[nenti]

I installed the warmup plugin to my project and just realized that it is not working properly.

The warmup-lambda is peroperly executing every 5 minutes:

The logs indicate a successful execution:

START RequestId: 3b04bd5d-7de1-11e8-8fdf-7b05371b3361 Version: $LATEST
2018-07-02T10:18:14.729Z	3b04bd5d-7de1-11e8-8fdf-7b05371b3361	Warm Up Start
2018-07-02T10:18:15.187Z	3b04bd5d-7de1-11e8-8fdf-7b05371b3361	Warm Up Invoke Success: glypo-dev-captureTransaction { StatusCode: 200, Payload: '"Lambda is warm!"' }
2018-07-02T10:18:15.187Z	3b04bd5d-7de1-11e8-8fdf-7b05371b3361	Warm Up Finished with 0 invoke errors

But the function monitoring on captureTransaction doesn't log an invocation:

Also the end to end test is still showing following load times on sequential execution:

Received: 4846
Received: 1537
Received: 1627
Received: 1580

[goncaloneves]

@nenti WarmUP invokes $LATEST Lambda alias which stores the Invocation metrics under your $LATEST Lambda Resource CloudWatch metric. That's why it doesn't show up on Lambda monitoring view.

You could just check by FunctionName Lambda metric and it will show up fine in CloudWatch.

And you could check your service warmed up functions CloudWatch logs which you can easily cross-check if they are invoked or not.

[nenti]

@goncaloneves thank you for clarifying this. I found the logs and it is invoked just fine. Problem is, that when I invoke my lambda it hits without the $LATEST and seems to hit an unwarmed instance. Although they hit the same version.

Please see the request times of my test.

[goncaloneves]

Are you running multiple version containers?
WarmUP guarantees one $LATEST version container warmed up. We discussed what would be the best approach to implement it at scale with multiple instances running in parallel in discussion #24.

[nenti]

No I only run one version of lambda. But still warmup invocations are showing up in different monitoring and the lambda doesn't seem to be warm when I invoke it.

Invocation comes from another service and is called like so:

      const params = {
        FunctionName: arn,
        InvocationType: async ? 'Event' : 'RequestResponse',
        Payload: typeof data === 'object' ? JSON.stringify(data) : data,
      }

      return this.lambda.invoke(params, (error, result) => {
        // do something
      })

[goncaloneves]

You are invoking without Qualifier parameter. It doesn't seem? Or it isn't? Check the logs of the functions you are warming up and confirm.

https://github.com/FidelLimited/serverless-plugin-warmup/blob/e1c6a9b1ef16260d9c7379efd15ea5ebec6b2a8e/src/index.js#L271

[nenti]

Yes I invoke without Qualifier. But it is not a recommended field in invoke. So shouldn't we be expecting people calling without Qualifier?

UPDATE: I tried hitting with Qualifiers set and now it lists in the same monitoring tab. First hit was still with almost a second delay again while execution time vary within 100ms.

Now first hit was 2400 ms (compared to >3000) only so closer to 2nd hit. Would there be any other layer that needs to be warmed when hitting a lambda from remote? Testsetup is running a local unit test that calls remote lambda. Could be that the unit-test is just running slower on initial execution.

[goncaloneves]

It is fine without Qualifier, by default it sets to $LATEST per AWS documentation. The only difference is the CW metrics are different. Not an issue.

If you are finding issues with cold starts, lower the schedule interval. I set to run every 2 minutes since in most use cases without external invocations most lambdas go cold around 3 minutes.

(Edit) Most containers regardless of activity go down around 15 minutes of uptime. The shorter the interval (1 minute minimum with CW Schedule), less likely your users will feel the cold start pain when there is no container up.

[ywang9009gmail]

Hi, is there a way to keep a specific version of function warm instead of $LATEST? Thanks