I'm initialising the DDB connection outside the function as you suggest. However, I'm calling context.succeed() not context.done() -- would this be problematic?
I'll try increasing the "memory size" and requesting an increased concurrent request limit too, thanks.
Thanks for the info on this, I hadn't seen Kinesis before. I also tried something similar with S3 upload but Kinesis looks a much better solution for what I'm trying to do.
Interesting that the article talks about load tests but omits any results.
I was trying out a Gateway API + Lambda + DynamoDB setup in the hope that it would be a highly scalable data capture solution.
Sadly the marketing doesn't match the reality. The performance both in terms of reqs/sec and response time were pretty poor.
At 20 reqs/sec - no errors and majority of response times around 300ms
At 45 reqs/sec - 40% of responses took more than 1200ms, min request time was ~350ms
At 50 reqs/sec - v slow response times, lots of SSL handshake timeout errors. I think requests were throttled by Lambda but I would expect a 429 response as per the docs rather than SSL errors.
My hope was that Lambda would spin up more functions as demand increased, but if you read the FAQs carefully it looks as though there are default limits. You can ask these to be changed but that doesn't make scaling very realtime.
Hey, I'm one of the developers at Songkick - I'd love to hear your feedback on the API. Feel free to reply here or email me paul.springett{at}songkick{dot}com
The caching part looks really interesting -- have you considered adding support for more fine-grained caching control, such as respecting etags and last-modified times?