AWS Lambda Runtime API

Server Development
#30

Good news! Can't wait to use it myself :slight_smile:

It could be interesting once it's stable to do some benchmarks to see if it's a competitive option for production use.

Update:
Well we already have some elements there about general Swift performance.

#31

@Damien_Petrilli , I like your idea.
I've opened an issue on the library, I would be very grateful if you can help me on this.


Feel free to open a new issue if this doesn't describe your idea.

You can consider the core LambdaSwiftSprinter package quite stable as it was ~100% tested (HelloWorld Example).

The unstable part is the one related to the nio 2.0 plugin and the aws-sdk as the related libraries are under development.

1 Like
#32

I’ve been using your runtime for a couple of months, and absolutely loving it! I’m getting 100ms round-trip times for AWS API calls but I don’t know if this is an issue with the way I’m using the AWS SDK (the open source one on Github that you reference in your examples) or something else. Any notes you could add to the Readme on performance tips would be amazing! Again, really great project!!!

2 Likes
#33

Hi @mr_j_tree - do you have any code to share? Have you tried out any logging or instrumentation around performance? What’s your code doing? Which services are you using? We’ll need more info to help diagnose.

#34

Also if anyone here is at Re:invent this week and wants to connect and/or help move Swift on lambda forward let’s chat

#35

Hi, I've been doing some investigation into this in the last week. You can see the results in this thread https://github.com/swift-aws/aws-sdk-swift/issues/202#issuecomment-560266370. Main things to extract from this are

  1. Most of the time is spent in the HTTP request part of the AWS API calls. This can be improved upon. The connection pool work that is happening on the async-http-client should improve things considerably if you are doing more than one api call in the lambda.
  2. cold starts hurt, really bad. The process of creating and signing a request takes over 100ms on the first call, subsequent calls it takes approx 1.5ms. If the lambda is warm the first call takes 1.5ms.
1 Like
#36
  1. I got same results. I'm waiting for the connection pooling in async-http-client before publishing the full comparison with other languages.
  2. The cold start issue is mitigated by the provisioned concurrency of AWS Lambda announced yesterday: https://aws.amazon.com/about-aws/whats-new/2019/12/aws-lambda-announces-provisioned-concurrency/
#37

Hi, I'm excited to share what I've been working on for the last two months or so.

Swift on Amazon Linux

I got Swift to compile on Amazon Linux 2. You can download the binaries from my website. If you want to see how the sausage is made, all scripts and Dockerfiles are public on GitHub. I would like to automate this process in so far that after a Swift release the whole release process is automated.

Swift on Amazon Linux Dockerimages

Another part of the amazonlinux-swift effort is to provide Dockerimages for your convenience at DockerHub to make compiling your Swift code for Amazon Linux 2 snappy.

Swift Lambda Layer

Even though I only made Swift compile on Amazon Linux 2, the libraries needed for running Swift are ABI compatible (pure luck, not official) with Amazon Linux 1. (Amazon Linux 1 is the operating system in which Lambdas without AWS provided runtime are executed.) Amazon Linux 1 is nearing end of life with support dropping on June 30, 2020. With this being said, AWS has to switch the underlying execution operating system to Amazon Linux 2 within the next 6 months. (They already have done that for node.js and Java)

Thanks to Swift running even on Amazon Linux 1, I have been able to create a Swift Amazon Linux Layer that links against Amazon Linux system libraries. The layer comes without any bootstrap and can be used in whatever way. You should bebe aware that you need an entrypoint (any executable named bootstrap) for execution. The Layers have already been uploaded in most AWS-Regions and are public for use in your Lambdas.

The scripts to create and distribute the Layers are part of the amazonlinux-swift project as well.

Since it is really just the Swift execution environment, it can be used with @Andrea-Scuderi's or @tonisuter's runtime. Since libFoundationNetworking links against the system's libcurl even https calls with NSURLSession are possible.

Swift-NIO opinionated AWS Lambda Runtime

I've created my own take on an AWS Lambda runtime called swift-lambda-runtime that builds on top of SwiftNIO and AsyncHTTPClient. The interface is Swift-NIO centric enabling the use of EventLoopFutures and an integration with swift-log. It includes a short tutorial on how to get your first Lambda running on AWS.

I'd be grateful for your feedback and hope that some of you enjoy this. I'm open to new contributors to this effort, just reach out.

29 Likes
#38

This is awesome, all of it! Thank you for your work on this!

I don’t currently have a use-case but I’m very interested in the NIO part of this. Was thinking of starting work on a SwiftUI-style GraphQL Server but don’t have time right now

#39

@GalCohen I have since realised what was going on with my AWS API calls from Lambda functions. I did not fully understand the way Lambda dynamically allocates CPU depending on your memory allocation. I was allocating the bare minimum of memory in order to save cost, without realising it was reducing available CPU time. Increasing memory allocation has got my DynamoDB API calls to perform at the expected speed... in the single digit millisecond range as advertised.

Cheers - lesson learned!

2 Likes
#40

I just wanted to give you folks a small update on swift-lambda-runtime: With the latest release I added event types for six different source events:

  • Application Load Balancer handler
  • APIGateway handler
  • Cloudwatch Scheduled Events
  • DynamoDB Streams
  • SNS Messages
  • SQS Messages

So If you want to consume a SNS message in your lambda your code would look like this:

struct SNSBody: Codable {
  let name: String
  let whatevar: String
}

func handleSNS(event: SNS.Event, ctx: Context) -> EventLoopFuture<Void> {
  do {
    let message = event.records.first!.sns
    let body: SNSBody = try message.payload()
    
    // handle your message
    
    return ctx.eventLoop.makeSucceededFuture(Void())
  }
  catch {
    return ctx.eventLoop.makeFailedFuture(error)
  }
}

// some more setup

let runtime = try LambdaRuntime.createRuntime(eventLoopGroup: group, handler: handleSNS)

You can get an idea of how to use the events by looking at my example: EventSources. In this package you can also find a template.yaml that can give you an idea on how to setup your surroundings with aws-sam.

If you have any questions please reach out: I'm @fabianfett on twitter or just open a GitHub issue.

9 Likes
#41

Just for completeness and information of everyone interested in Lambda:

I started a discussion about how a Linux distribution other than Ubuntu can be officially supported by Swift: Official platform support for other Linux Distributions (and a case for Amazon Linux 2)

Maybe you are interested in this?

2 Likes
#42

Hi all,

I finally completed the performance evaluation of Swift on AWS Lambda, I’ve published all the results in this article

I compared Swift performances not only among different languages but also between Ubuntu and the Amazon Linux 2 build provided by @fabianfett.

It’s well known that the overall performance of lambda is dependent on the code size and the allocated memory (and vCPU).

I compared the performance of lambda with the same amount of Memory and vCPU using a basic HelloWorld example.

Refer to this article to better understand what is Cold and Warm start and how AWS Lambda works https://dev.to/sosnowski/anatomy-of-aws-lambda-1i1e.

AWS Swift vs other Languages

  • Code size gives an advantage to all the runtimes already supported by AWS
  • Cold Start for Swift is ~190ms, Go ~75ms, Python ~127ms, NodeJS ~128ms
  • Warm Start for Swift is ~1.19ms, Go ~0.44ms, Python 1.34ms, NodeJS ~1.06ms

With a small penalty on cold start the performance of Swift is comparable to Python and NodeJS

AWS Swift Lambda Layer Ubuntu vs Amazon Linux 2

  • The Amazon Linux 2 custom run time is around ~20MB and the Ubuntu custom runtime is ~40MB
  • The reduced size of code gives at Cold start advantage of ~140ms to Amazon Linux 2 [Amazon Linux 2 (~190 ms) vs Ubuntu (~329 ms)]
  • At warm start there is no substantial difference between Amazon Linux 2 and Ubuntu.

The small penalty paid by Ubuntu is compensated by a more stable and certified building pipeline.

Swift with libCURL vs AsyncHTTPClient (Swift NIO)

Swift-Sprinter vs Swift-NIO opinionated AWS Lambda Runtime

  • Both framework use Swift NIO
  • Swift Sprinter performs slightly better with a difference of ~0.20 ms at warm start
  • On cold start it depends on the runtime version.
  • Swift Sprinter can be built with Ubuntu and Amazon Linux, Swift-NIO opinionated can be built only with Amazon Linux 2

Conclusions

Swift using AsyncHTTPClient NIO with connection Pooling shows good performance on AWS Lambda compared to most popular languages.

The only advantage of using Amazon Linux 2 rather than Ubuntu is given by ~140ms on cold start, when there is no much difference at warm start.

In the wait to have a stable Amazon Linux 2 swift version, we should note that this advantage is not so huge and can be mitigated using provisioned concurrency.

7 Likes
#43

Thanks for the interesting insight, I just read the results but it seems like a good enough spot to be in.

#44

Thanks very much for this analysis @Andrea-Scuderi. I agree that this is a pretty good spot to be in. However even with the connection pool we're (1.19ms for a warm start) still considerably slower than Go (0.44ms for a warm start). Do you have an idea where that time is lost?

#45

Hi @johannesweiss,
I was disappointed too... we all want to win :smiley: the language challenge.

I added an enhancement request on the Swift-Sprinter repository https://github.com/swift-sprinter/aws-lambda-swift-sprinter/issues/38 .

I'll add consideration there to avoid noise on the forum. Happy if you can take a look to it and if you can give some suggestion on how to evaluate internal performances.
I added the code in the issue so it can be easy to follow.

Principal suspects we need to investigate more:

  • In the Go example, the lambda doesn't pass the Data and Context buffer
  • Some evaluation/instance of the Data/Context could be improved in Swift
  • AsyncHTTPClient performance could be improved
#46

These results are on an optimized build, right? Sorry, just triple checking :sweat_smile:

1 Like
#47

That sounds interesting, which particular bit shows up is slow in your benchmarking/profiling?

#48

The build has been built with release flag.

1 Like
#49

@johannesweiss
I added some log to print the value. (This alter for ~0.20 ms the duration).

START RequestId: 8e120434-2108-4a59-9bb4-956b6a6b5e84 Version: $LATEST
   nio-plugin: 1065.549714000099ms:httpClient.execute
   nio-plugin: 0.00033700007406878285ms:result.status.isValid()
   nio-plugin: 0.003169000137859257ms:body.getData(at:...)
core: 1065.6208529999276ms: getNextInvocation
core: 0.008160000106727239ms: lambdaRuntimeTraceId
core: 0.000874000306794187ms: lambdas[handlerName]
core: 0.008774999969318742ms: context
core: 0.005031999990023905ms: commonHandler
   nio-plugin: 0.05818800036649918ms:.data(httpBody)
   nio-plugin: 0.488504999793804ms:httpClient.execute
core: 0.5696690000149829ms: postInvocationResponse
core: 0.0049599998419580515ms: wait
END RequestId: 8e120434-2108-4a59-9bb4-956b6a6b5e84
REPORT RequestId: 8e120434-2108-4a59-9bb4-956b6a6b5e84	Duration: 1.42 ms	Billed Duration: 100 ms	Memory Size: 256 MB	Max Memory Used: 84 MB

Results:
Total time: 1.42ms
getNextInvocation = ~0.82253ms (evaluated by difference excluding other internal times)
postInvocationResponse = ~0.5696690000149829ms

the AsyncHTTPClient post run in ~ 0.488504999793804ms
(AsyncHTTPClient from current master branch)

I've added a full report in this issue: https://github.com/swift-sprinter/aws-lambda-swift-sprinter/issues/38

Note:
By adding Data/Context to the golang example the result doesn't change (~0.44ms in total)

Terms of Service

Privacy Policy

Cookie Policy