Finding performance boosts in serverless applications

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 sourceslambdas 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…

  1. event object from the event source
  2. context object provides methods to interact with runtime info (request ID, log group, timeout, etc.)
  3. initialization inclusion of dependencies, establishing database connections, and importing secrets and initialization variables.
  4. handler function the function to be executed upon each invocation
  5. 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

  1. Separate Lambda handler code from core logic
  2. Use functions to TRANSFORM, not TRANSPORT
  3. 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.
  4. Read-only what you need – efficient requests against DB, use views and S3 select etc.
  5. No orchestration in code
  • retries of network requests etc
  • failure handling INSTEAD: use step functions (retry logic, orchestration logic, workflow logic out of lambda)
  1. 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

  1. More memory == More CPU and I/O (proportionally)
  2. Use AWS X-ray to profile your workload
  3. 1.8GB === 2 cores, but you might not use/need it

  4. Think deeply about your execution model and invocation source needs (not everything needs to be an API)
  5. Understand various aspects of queues, topics, and streams when using them
  6. VPC has benefits but isn’t necessary for security
  7. Minimize scope for IAM permissions

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

Read our blog

Why and How to Monitor AWS Elastic Load Balancing

Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!

Monitor Your AWS AppSync GraphQL APIs with Simplicity

Dashbird has just added support for AppSync to help you monitor all of your AppSync endpoints without needing to browse dozens of logs or stumble through traces in the X-Ray UI.

AWS AppSync as a Gateway to Your Cloud Infrastructure

This article will discuss AppSync, AWS’s managed GraphQL service. Read on if you’re building a new backend or want to see if there is a more refined solution to the gateway problem than ELB and API Gateway.

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.

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.