npgsql/npgsql

Allow users to specify extra capacity in the pool

roji opened this issue · 2 comments

roji commented

Originally raised by @Toxantron in npgsql/EntityFramework6.Npgsql#156.

Our pool is currently designed to try to have 0 idle connectors at any given point, i.e. align to the application's exact connection needs. Although this optimizes for PostgreSQL server resources (for reducing idle connections as much as possible), it means that when load increases applications suffer latency issues as new physical connections need to be opened. This causes unpredictable latency and jitter in responses.

Possible mitigation:

  • Add a configuration knob to allow the user to specify extra pool capacity (e.g. target 2 connections more than is typically needed)
  • When opening a new physical connection, open additional connections to meet the extra capacity, in the background. This means that if we have one idle connection in the pool and the application requests it, we will immediately open additional new physical connections to maintain idle capacity.
  • When pruning connections, take account of the extra capacity as well (prune less)
  • An additional, somewhat-related change would be to always open additional connections in the background to meet Min Pool Size, so the first Open in the application would immediately bring us to the minimum. We currently don't do this, and apply Min Pool Size only for pruning purposes.

In effect, this is a tradeoff between between latency for Open, and minimizing the number of unused PostgreSQL connections kept open by the application. I can see this being useful to a lot of people - latency is indeed important, and I suspect many would be willing to pay for that with some extra unused capacity.

Note that this would be relevant also in multiplexing mode.

If anyone wants to work on this, please post here first and wait for confirmation as some considerable work is going into the pool at the moment.

/cc @NinoFloris

An additional, somewhat-related change would be to always open additional connections in the background to meet Max Pool Size, so the first Open in the application would immediately bring us to the minimum. We currently don't do this, and apply Max Pool Size only for pruning purposes.

I think you meant MinPoolSize, didn't you?

roji commented

Yep, thanks! Corrected.