3 ms·
Right, and one of biggest downsides to serverless: reusing database connections/pools between requests. Right now the only "standard" solution offered by server
by igammarays 9y ago
Right, and one of biggest downsides to serverless: reusing database connections/pools between requests. Right now the only "standard" solution offered by serverless's biggest advocates is pretty much a hack: rely on AWS's preservation of memory across some warm invocations. Basically keep it in a global variable and if you get lucky it'll still be there the next time your functions runs.
[1] http://blog.rowanudell.com/database-connections-in-lambda/ http://blog.rowanudell.com/database-connections-in-lambda/
- devonkim 9y agoI think a mixture of persistent proxies could work well with lambda functions for this use case. You can run lambdas in your VPCs with assigned security groups and IAM roles just like an EC2 instance and therefore lambda functions should be able to proxy through an intermediate server that performs the connection pooling on behalf of calling functions. Not sure what the standard solution for something like this would be though because every time I've seen connection pooling it's for use locally. Perhaps some nginx or haproxy hacking could make it work.
- matt_wulfeck 9y agoIn this scenario you’re still paying the cold-connection cost to your proxy, and that’s just keeping a pool of tcp connections open, not necessarily doing anything smart/optimized in the sql driver.
- paulddraper 9y agoThat's not really a "hack" though. Performance of lambda depends on warm processes, generally not just for connection pooling. DB connection pooling is simpler in node.js + lambda than php + Apache.