You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "FlorianHockmann (GitHub)" <gi...@apache.org> on 2018/12/19 14:49:48 UTC

[GitHub] [tinkerpop] FlorianHockmann commented on issue #1016: WIP: Add request pipelining and ConnectionPool sizes TINKERPOP-1775 and TINKERPOP-1774

> I would recommend to remove the dynamic pool sizes (min/max), but I leave it up to you. In my experience, the use for dynamic pools is very limited. Usually when there is spike in requests, opening new connections can lead to a latency with no added benefit (there is a limited number of requests that a server can process at any given time).

You mean that the pool should simply have a fixed size instead? Wasn't that what you asked for in TINKERPOP-1774:

> Similar to the java connection pool, we should limit the maximum amount of connections and start with a minimum number.

or what do you mean exactly with dynamic pool sizes?

I don't really have a strong opinion on that. My assumptions was just that it's probably hard for users to set a good value for the size. Dynamic pool sizes basically avoid this as the pool will automatically grow to a size that is big enough to handle the number of parallel requests the application typically uses. Later on, we could also add a mechanism to remove idle connections if they were only created because of a spike in requests as too many idle connection seem to be problematic with certain providers (especially CosmosDB, judging from the tickets we currently have open). Although this mechanism would of course make the latency problem even worse for spikes when the connections were already closed again since the last spike.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1016 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org