4 ms·

The other problem with Lambda is that you cannot keep persistent connections in a connection pool. It is after all, designed for statelessness. This can be cons

by gshx 11y ago

The other problem with Lambda is that you cannot keep persistent connections in a connection pool. It is after all, designed for statelessness. This can be considerable cost for doing calls to other business services (http connection pools) or infra services like databases that all maintain persistent connections.

falcolas 11y ago
Absolutely. The overhead of re-establishing a secure DB connection for every request is hardly trivial.
- wsh91 11y ago
  It would be, if it were necessary, but it's not. (Static initializers or default constructors in Java, for example.)
  - falcolas 11y ago
    Question then: How do you omit the overhead of setting up a new socket and all of the SSL handshakes? I'm not concerned about the Java overhead associated with new connections, I'm concerned with the raw connectivity/handshake overhead required with new connections to the DB.
    - wsh91 11y ago
      It happens once, on initialization. :) The first execution takes anywhere from 50-70 seconds, for sure, but reusing the connection afterwards means subsequent ones don't have to deal with it (100-200 ms a pop). (Does that make sense?)
      - ec109685 11y ago
        50 seconds?
wsh91 11y ago
This isn't true. I run a Lambda right now that queries a Cassandra connection pool at high volume. In Java, at least, you set up your resources in a static initializer block, as this alludes to. http://docs.aws.amazon.com/lambda/latest/dg/best-practices.html http://docs.aws.amazon.com/lambda/latest/dg/best-practices.h... Problem solved.