tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jorgebay <...@git.apache.org>
Subject [GitHub] tinkerpop issue #903: Gremlin.Net: Add ConnectionPool min and max sizes TINK...
Date Fri, 07 Sep 2018 07:47:49 GMT
Github user jorgebay commented on the issue:

    https://github.com/apache/tinkerpop/pull/903
  
    > Do you see other advantages?
    It allows the client to prime the server with enough requests in order to support maximum
throughput. Considering the multithreaded asynchronous nature of the server, there is far
more advantages in request pipelining than with multiple connections.
    Considering that the server is multithreaded, you can think multiple connections w/o request
pipelining as a system using multiple threads and blocking on each thread; being a single
connection with request pipelining the equivalent of async non-blocking code.
    
    Additionally, supporting the same (or more) throughput with fewer connections has the
advantage of having less memory consumption and being able to support a greater number of
clients.
    
    Regarding the relation of this ticket with TINKERPOP-1775, I think we have 2 options:
    a) We see this change as an incremental improvement (which definitely is) without considering
TINKERPOP-1775.
    b) We try to think now how TINKERPOP-1774 and TINKERPOP-1775 will come into place together,
regardless of which we implement first. I think the ultimate solution would be for the pool
to balance request between connections, and without taking them out of the pool each time
a request/response is issued.
    
    I think we should take the approach in B, otherwise implementing it without thinking of
TINKERPOP-1775 might introduce unnecessary complexity (i.e: a queue of pools that get enqueued
and dequeued all the time).



---

Mime
View raw message