https://serverless-stack.com/ logo
Join Slack
Powered by
I have a nodejs lambda triggered by an API Gateway...
# help
r
I have a nodejs lambda triggered by an API Gateway HTTP API endpoint that’s taking 6-7s to run when cold starting according to Postman. The Thundra reported execution time is around 3s. The returned payload is 2kb. It’s a GET request so there’s no data payload. No VPC involved. Any thoughts on how I can narrow down where those other 3-4s going?
t
Weird! Only idea I have for you is to add logging to api gateway to see what it thinks is going on https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-logging.html
That should show whether its an aws issue or something between you and aws
r
Thanks, I'll give that a go
g
The size of node_modules and the code you execute outside of lambda handler also impacts the cold starts.. when you lambda is executed, aws make sure everything else is ready/loaded for that run.
So maybe this is taking time to load
r
Yeah, we’ve put the aws-sdk-v3 libs in a layer. we’re careful to import only what we need. The full package size reported in the console is only 710kb
Weirdly, re logging. I have 
accessLog: true
in the API definition in my stack but the console says
f
@Ross Coundon re logging, if u run 
sst build
, check the CF template in 
.build/cdk.out
> look for the 
AWS::ApiGatewayV2::Stage
resource
Do u see 
AccessLogSettings
inside the 
Properties
?
r
Nope
Copy code
"Stage0E8C2AF5": {
      "Type": "AWS::ApiGatewayV2::Stage",
      "Properties": {
        "ApiId": {
          "Ref": "ApiCD79AAA0"
        },
        "StageName": "cutomer-dev",
        "AutoDeploy": true,
      
      },
      "Metadata": {
        "aws:cdk:path": "somepath/Stage/Resource"
      }
    }
f
Oh wait.. I recall u were doing some custom stage stuff
lemme take a look at the accesslog logic for that
r
yeah, that’s right, we have a custom stage
so we do
Copy code
httpApi: {
        createDefaultStage: false,
      },
and
Copy code
new HttpStage(this, 'Stage', {
      httpApi: api.httpApi,
      stageName: this.stage,
      autoDeploy: true,
    });
f
Ah… accessLog is only enabled for the default stage
lemme give u the code on how to enable it
Create a log group first
Copy code
import * as logs from "aws-cdk-lib/aws-logs";

const logGroup = new logs.LogGroup(scope, "AccessLog", {
  logGroupName: `/aws/vendedlogs/apis/${stage}-${api.httpApi.apiId}`
});
And in ur HttpStage
Copy code
new HttpStage(this, 'Stage', {
  httpApi: api.httpApi,
  stageName: this.stage,
  autoDeploy: true,
});
r
Thanks Frank, seems the HttpStageProps doesn’t have destinationArn
Copy code
Object literal may only specify known properties, and 'destinationArn' does not exist in type 'HttpStageProps'.
f
And for the 
format
, take this array, and do
Copy code
const format = "{" + defaultHttpFields.join(",") + "}";
My bad, not supported by CDK yet, do this:
Copy code
const apiStage = new HttpStage(this, 'Stage', {
  httpApi: api.httpApi,
  stageName: this.stage,
  autoDeploy: true,
});
apiStage.node.defaultChild.accessLogSettings = { format, destinationArn };
Oh btw, I’d double check the cold start and duration number against the Lambda CloudWatch log (ie. the 
Duration
and 
InitDuration
fields)
r
Thanks Frank. I’ve tried removing the Thundra layer and that halves the time, so pretty sure it’s to do with that initialisation, it’s a bit weird as I’m not seeing the same on other lambdas that have Thundra in place so working it through with the team over there
Is that the right path?
f
u might’ve to cast it
Copy code
import * as cfnApig from "aws-cdk-lib/aws-apigatewayv2";

const cfnStage = apiStage.node.defaultChild as cfnApig.CfnStage;
cfnStage.accessLogSettings = { format, destinationArn };
r
Got ya
Worked a treat, thank you
2 Views
Open in Slack
PreviousNext
Powered by