4 ms·
One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down
by gshx 10y ago
One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down and restarting them is expensive and wipes out all hot path optimizations made by JIT compilers besides having to reestablish connections and pay the handshake prices. Apart from the simplest of use-cases at this time, imho this is not an efficient model if sustained performance and low latency are of interest.
- audleman 10y agoI've been wondering this same thing. We use gunicorn to handle our web requests and it pre-loads our code so it's ready at the drop of a hat to serve a request. It takes a few seconds to load up our site, so wouldn't Lambda have to pay that cost with every web request? I've been going under the assumption that it's just not the right use case for Lambda, though I'm hoping I'm wrong.
- jwatte 10y agoIf you have any kind of real load, there skills always be instances running. If you have less load than that, you are not a case worth optimizing for, because you pay less than a few hundred per month. Also, small instances are cheap to keep around, and as you pay per request, it's in the providers best interest to make that efficient. Well, that's the sales pitch, anyway...