4 ms·

API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gatew

API Gateway adds around 200ms to each call for us based on our testing plus another 100ms if it’s inside a VPC. What region are you in? Our VPC has a NAT Gateway so that our Lambda functions can talk to the internet as well. I am by no means an expert and am reporting what watching the time differences between Lambda reporting and our network calls shows. Edit: this is by no means a deal breaker or anything. Just something that shocked me when I first noticed it.

philliphaydon 9y ago
(crap I just typed stuff out and pressed F5...) I haven't tried with a NAT Gateway. This is what I know. If the response is small, the request duration is small. Cloudfront > Gateway > Lambda > RDS (PostgreSQL) Response: 1k | 20ms-60ms 10k | 50ms-90ms 100k | 150ms-200ms 350k | 200ms-450ms That's a rough gauge of what I've experienced. I think the throughput on the gateway is the bottleneck.
- Prefinem 9y ago
  Just hit one of our test endpoints Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms) Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms) Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms) This is for a 20kb payload single request. Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch
  - digitalsanctum 9y ago
    I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?
    - Prefinem 9y ago
      Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.
- Prefinem 9y ago
  Just a follow up, after the issue last week with AWS Lambda in East-1 (thursday I believe) VPC is not longer causing any additional overhead. I am not sure what happened, but I had to move a couple of functions inside the VPC and our response times have remained the same.
ec109685 9y ago
Are you paying for ssl round trips in your tests? We haven't seen such slow response times with lambda or the gateway.
- Prefinem 9y ago
  I don't believe so. I am using Chrome network data and the SSL has already been downloaded / cached.

philliphaydon 9y ago

(crap I just typed stuff out and pressed F5...) I haven't tried with a NAT Gateway. This is what I know. If the response is small, the request duration is small. Cloudfront > Gateway > Lambda > RDS (PostgreSQL) Response: 1k | 20ms-60ms 10k | 50ms-90ms 100k | 150ms-200ms 350k | 200ms-450ms That's a rough gauge of what I've experienced. I think the throughput on the gateway is the bottleneck.

Prefinem 9y ago
Just hit one of our test endpoints Test #1 Lambda run time (140 ms) Total waiting time (354ms) Total time (358ms) Test #2 Lambda run time (300 ms) Total waiting time (490ms) Total time (567ms) Test #3 Lambda run time (139 ms) Total waiting time (479ms) Total time (485ms) This is for a 20kb payload single request. Stack: Custom Domain -> Cloudfront -> API Gateway -> VPC -> Lambda -> NAT Gateway -> ElasticSearch
- digitalsanctum 9y ago
  I'm curious why you have a NAT gateway between your Lambda and Elasticsearch?
  - Prefinem 9y ago
    Lambda is inside the VPC which means it can’t connect to the outside world without a NAT Gateway.
Prefinem 9y ago
Just a follow up, after the issue last week with AWS Lambda in East-1 (thursday I believe) VPC is not longer causing any additional overhead. I am not sure what happened, but I had to move a couple of functions inside the VPC and our response times have remained the same.

ec109685 9y ago

Are you paying for ssl round trips in your tests? We haven't seen such slow response times with lambda or the gateway.

Prefinem 9y ago
I don't believe so. I am using Chrome network data and the SSL has already been downloaded / cached.