Finding performance boosts in serverless applications

Taavi Rehemägi

May 5th, 2019

From launching Dashbird one and a half years ago, our team has been in contact with a lot of companies building serverless applications and one of the problem areas that keep popping up are performance or cost issues. Performance problems usually present themselves when some best practices are overlooked or a suboptimal architecture decision have been made. This article is focused on how to look for optimization opportunities and to capitalize on those opportunities.

While serverless applications usually consist of event sources, lambdas functions, and external services, functions almost always present the most opportunity for optimization. Mainly because as a developer, you have less control over (managed) event sources and external services. To spot opportunities for efficiency, let’s look under the hood for a second and identify where we should look.

Anatomy of a Lambda function

Breaking a Lambda function into pieces you can see there are multiple places to look for optimizations.

Your function code is usually the biggest opportunity for optimization and a threat of making mistakes.
Language runtime, Python, Go binary Node.js etc. does not allow optimization.
Execution environment is a somewhat unintuitive place to think about but it can have an effect on performance. For example, how a function is invoked, is it in VPC, and needs an ENI? Are there too many redundant packages?
Compute substrate also allows no optimization. AWS controls this and there’s nothing you can do about this.

Structuring Lambda code for performance

Let’s start with what you can do in your code since it’s by far the most significant part of your application. Let’s break it down into smaller parts first…

event object from the event source
context object provides methods to interact with runtime info (request ID, log group, timeout, etc.)
initialization inclusion of dependencies, establishing database connections, and importing secrets and initialization variables.
handler function the function to be executed upon each invocation
business logic outside of the handler function

Initialization

Since initializations take place once for every time a container starts

For function initialization, the key things to think about are reducing the size of dependencies and reusing database connections.

minimize dependencies
use pre-handler logic strategically
Share secrets based on application scope
- single fn: env vars are most lightweight but don’t scale
- multi fn: parameter store
think about how re-use affects variables, connections, and dependency usage

Concise function logic

Separate Lambda handler code from core logic
Use functions to TRANSFORM, not TRANSPORT
Dynamic logic via configuration – if it does something differently in dev than in prod, don’t build that into your code but use env variables.
Read-only what you need – efficient requests against DB, use views and S3 select etc.
No orchestration in code

retries of network requests etc
failure handling INSTEAD: use step functions (retry logic, orchestration logic, workflow logic out of lambda)

Project & repository scoping (kk)

Context object

Mostly you won’t interact with it, but you can look where the logs go and what the timeout is and can make decisions whether to put something in the queue or execute it right now.

Lambda processes a single event per execution environment and reuses containers for consecutive events. The container is kept alive for 5-15 minutes and the amount of concurrent requests dictates the number of “frozen” containers that AWS keeps alive. For consecutive requests, only the handler function is re-executed and not the initialization part.

Optimizing execution environment

More memory == More CPU and I/O (proportionally)
Use AWS X-ray to profile your workload
1.8GB === 2 cores, but you might not use/need it
Think deeply about your execution model and invocation source needs (not everything needs to be an API)
Understand various aspects of queues, topics, and streams when using them
VPC has benefits but isn’t necessary for security
Minimize scope for IAM permissions

This article is based on the talk about optimizing serverless applications @reInvent 2018

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

Get started free or learn more

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.