You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, again thanks for putting this sample together, it is much appreciated.
I'm wondering why, unlike the other lambda functions that have 128MB as default, DDBStreamsFunction has MemorySize: 3072. I couldn't find it in the commit history, and it seems to use 24MB or so (which is great!) when running the tests.
The text was updated successfully, but these errors were encountered:
My original reasoning was that, since DDBStreamsFunction will process batches of up to 1000 events, I should allocate more memory to the function to also get more CPU and network resources to speed up the transformation. So this was not driven by memory usage, but for CPU/networking resources.
In reality, the function spends a lot of time waiting for the EventBridge PutRecords API anyway. I just did a test at 128MB and 3072MB under heavy load to compare. The functions takes on average 700ms at 128MB, versus 200ms at 3072MB. As this function is not latency-sensitive, it's best to optimize on costs. I'll make a change lowering the memory to 128MB.
Hi, again thanks for putting this sample together, it is much appreciated.
I'm wondering why, unlike the other lambda functions that have 128MB as default, DDBStreamsFunction has
MemorySize: 3072
. I couldn't find it in the commit history, and it seems to use 24MB or so (which is great!) when running the tests.The text was updated successfully, but these errors were encountered: