[gshx]

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]

I'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]

If 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...