I'm definitely excited about this, especially after paying $36/month for a NAT that I barely used for a long, long time, and spending too many hours configuring it for my Lambdas.
That said, I don't know how Jeremy Daly got away with making that post, per AWS preview terms. They are pretty explicit about not posting benchmarks on their preview products, and that makes sense as the API is not stable at all.
Still, I'm glad to see the data and hope that the performance has improved. I wasn't accepted into the preview, and I've started work now to move most of our infrastructure to GCP. It notably does not require any fancy footwork to have a Cloud Function talk to a Cloud SQL instance https://cloud.google.com/functions/docs/sql#overview
Wait if I read that doc correctly, does it seem to suggest that connections will be closed when the function goes cold. So the locked up connections where lambda dies without disconnecting isn’t a problem google functions?
Think of a spike in traffic, 100 functions connect one connection per function. Then a break 80 of them go cold. Your max connections is 100, so if 80 didn’t disconnect and are waiting to timeout you are stuck. Any more functions coming online won’t have any connections.
The only work around in AWS was to setup an external connection pool, kind of begins to kill the serverless savings and all.
Jeremy has updated the post in response to the announcement.
- Lots of improvements & better documentation
- Smaller response size, but can be cut down a lot more
- Sub 100ms query performance
> I’m really impressed by the updates that have been made. I do want to reiterate that this isn’t an easy problem to solve, so I think the strides they’ve made are quite good. I’m not sure how connection management works under the hood, so I’ll likely need to experiment with that a bit to measure concurrent connection performance.
Does anyone have performance feedback now that it is no longer beta?