Lambda optimization tip — enable HTTP keep-alive

Yan Cui
Yan Cui
Feb 2, 2019 · 4 min read

I recently watched an excellent talk by Matt Lavin on optimization tips for Lambda and saw a slide on making DynamoDB use HTTP keep-alive. It reminded me of a conversation I had with Sebastian Cohnen, so I set out to test the effect this simple optimization has.

Image for post
Image for post

What is it all about?

As it turns out, Node.js’s default HTTP agent doesn’t use keep-alive and therefore every request would incur the cost of setting up a new TCP connection. This is clearly inefficient, as you need to perform a three-way handshake to establish a TCP connection. For operations that are short-lived (such as DynamoDB operations, which typically complete within a single digit ms) the latency overhead of establishing the TCP connection might be greater than the operation itself.

With the Node.js AWS SDK, you can override the HTTP agent to use for ALL clients with just a few lines of code. You can also override the settings for individual clients too.

Image for post
Image for post

UPDATE 22/09/2019: since AWS SDK v2.463.0 you no longer need these couple of lines of code change any more. Instead, set the environment variable AWS_NODEJS_CONNECTION_REUSE_ENABLED to 1 to make the SDK reuse connections by default.

The tests

To test the effect of enabling HTTP keep-alive, I setup a simple Lambda function behind API Gateway. Essentially this function puts an item into a DynamoDB Table, and that’s it.

Image for post
Image for post

For this experiment, I wanted to see how well the HTTP keep-alive fared across multiple invocations and how much of a difference do we see with this simple change.

The results

Without HTTP keep-alive, the DynamoDB operation averaged around 33ms.

Image for post
Image for post

With HTTP keep-alive, that average drops to around 10ms.

Image for post
Image for post

As we suspected, the overhead (33ms-10ms = 23ms) was greater than the cost of the operation itself. The experiment shows that the connection is reused across multiple invocations just fine. With a very simple change, we were able to improve execution time by ~20ms, or to put it more impressively, reduce response time by 70%. That’s good return on investment in my book, but the difference is still not noticeable to the human eye.

But what if we scale this to 10 sequential DynamoDB operations in a single function?

With HTTP keep-alive, the function’s execution time averages around 60ms.

Image for post
Image for post

Without HTTP keep-alive, the average execution time rises to 180ms.

Image for post
Image for post

As I curl the endpoint, the difference of 120ms is definitely noticeable. This difference can start to impact user experience, and as Amazon found 10 years ago, adding 100ms of latency can reduce sales by as much as 1%.

Image for post
Image for post

Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Don’t worry, I’m here to help. Let’s talk!

If you enjoyed this article, why not follow me and get even more?

I would appreciate your support on Patreon too. And in return, you can get direct help from me via a private Slack channel and 1–2–1 mentoring.

Image for post
Image for post
Image for post
Image for post

Check out my new course, Complete Guide to AWS Step Functions.

In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, design patterns and best practices.

Get your copy here.

Image for post
Image for post

Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.

You can also get 40% off the face price with the code ytcui.

Get Your Copy

Sign up for Predict Newsletter

By Predict

Monthly updates on science and technology shaping our future. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Yan Cui

Written by

Yan Cui

AWS Serverless Hero. Independent Consultant https://theburningmonk.com/hire-me. Author of https://productionreadyserverless.com. Speaker. Trainer. Blogger.

Predict

Predict

where the future is written

Yan Cui

Written by

Yan Cui

AWS Serverless Hero. Independent Consultant https://theburningmonk.com/hire-me. Author of https://productionreadyserverless.com. Speaker. Trainer. Blogger.

Predict

Predict

where the future is written

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store