added some more performance stats

Author: Jan Kammerath

README.md

@@ -4,7 +4,7 @@ This is a boilerplate application that shows how to run a serverless Swift appli
 
 ## A note on Vapor
 
-The vapor integration curently uses the `AsyncHTTPClient` and thus the local loopback on the Lambda instance. Also Vapor does not seem to be initialized when the Lambda cold starts, but with every invocation of the Lambda. That still needs fixing and testing. 
+The vapor integration curently uses the `AsyncHTTPClient` and thus the local loopback on the Lambda instance. Vapor is initialized when the Lambda container first starts making the cold start take around 800-900ms on a 128 MB arm64 container running Amazon Linux 2. There is no measurable performance impact on using the loopback adapter within the VaporProxy class that then sends the HTTP request to the vapor app running on port `8585``.
 
 ## Running locally
 
@@ -15,6 +15,8 @@ make build
 sam local start-api --template template.yaml
 ```
 
+Note that the performance characteristics of running this application locally using AWS SAM is entirely different from running it on AWS. SAM will use approx 30-40% more memory than the binary will consume with the actual Lambda on AWS. The invocation of SAM will also take more time than it will when actually running on Lambda with API Gateway.
+
 ## Sample logs
 
 The logs give an insight on the performance of the approx. 117 MB binary file within the Lambda. The Lambda cold start with the binary is a little less than 1 second. The log also shows how Vapor runs through the entire lifecycle of the Lambda and is reused for subsequent requests to the same Lambda container. The memory consumption of 39 MB on a 128 MB instance is perfectly in line with web frameworks of Vapor's scale (e.g. Go Gin). The logs do not show any reasonable performance impact of the usage of the loopback adapter in the VaporProxy class.