Re: Batch insert heavily affecting query performance.

On Wed, Dec 27, 2017 at 2:10 PM, Mike Sofen <msofen(at)runbox(dot)com> wrote:

> In my experience, that 77ms will stay quite constant even if your db grew
> to > 1TB. Postgres IS amazing. BTW, for a db, you should always have
> provisioned IOPS or else your performance can vary wildly, since the SSDs
> are shared.
>
>
>
> Re Lambda: another team is working on a new web app using Lambda calls
> and they were also experiencing horrific performance, just like yours (2
> seconds per call). They discovered it was the Lambda connection/spin-up
> time causing the problem. They solved it by keeping several Lambda’s
> “hot”, for an instant connection…solved the problem, the last I heard.
> Google for that topic, you’ll find solutions.
>

You should try to implement an internal connection pool in your lambda.

Lambda functions are reused. You have no guarantees as to how long these
processes will live, but they will live for more than one request. So if
you keep a persistent connection in your lambda code, the first invocation
may be slow, but further invocations will be fast. Lambda will try to batch
several calls at once. In fact, you can usually configure batching in the
event source to try to maximize this effect.

In my experience, your lambda will be most probably network-bound. Increase
the lambda's memory allocation, to get a bigger chunk of the available
network bandwidth (why they decided to call that "memory" nobody will ever
be able to tell).