Which would you expect would be faster, SNS directly invoking a Lambda function? Or SNS to SQS to a Lambda function?
Here's a fun thread documenting what I've learned!
π§΅π #Serverless
In a totally unscientific test (N=3), Iβve observed SNS messages delivered directly to Lambda functions are slower than an SNS message sent to SQS, then delivered to Lambda.
Check out the following trace:
Here, the SNS message is published from the initial lambda function (purple spans). You then see the fan-out, with the yellow span indicating the time for SNS to invoke my function, and the two blue spans representing the time for SNS to SQS and then invoking my function.
The consuming functions are identical clones, and the init duration was within ~10ms for both functions, but the start times of both functions are separated by 75ms (average over 3 tests).
In this case, itβs about a 40ms difference.
@dougmoscrop helpfully pointed out that this could be explained by the fact that SNS triggers Lambda functions using an (asynchronous) Event invocation method, whereas SQS utilizes the Request/Response (synchronous) method.
This seems plausible!
Either way, it was a fun tidbit to learn, and it didn't quite fit the format of a blog post - so I hope you enjoyed this instead!
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
DynamoDB streams are GREAT! I use them in almost every place I use a DDB table with #Serverless. I suggest doing non-essential work via stream vs in one long function call, so the end user gets the fastest experience possible.
This is an important function, but users shouldn't have to wait for my API to call an email provider before getting a response from the backend. Stream it to another function!
@fitzsimons_dev@dynamodb 2. Stateful/synchronizing needs! Lambda functions are a distributed system, no way around that (unless you set function concurrency to 1, but I digress). So you need to build idempotency into your app.