[ 
https://issues.apache.org/jira/browse/TINKERPOP-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16943108#comment-16943108
 ] 

Stephen Mallette commented on TINKERPOP-2205:
---------------------------------------------

I'm just playing around at the moment. My approach is fairly naive since i'm 
just testing locally on my laptop and figured I should get roughly the same 
amount of RPS as I was before given the same local setup. I use this utility:

https://github.com/apache/tinkerpop/blob/master/gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/driver/util/ProfilingApplication.java

which I've tweaked locally at this point to work the changes on {{driver-35}}. 
I expect to push those shortly when my last round of configuration options 
completes execution.  I usually use this little tool to grab JFRs or to 
exercise the driver/server a bit after major changes. It's also only testing 
scripts at the moment, though that probably doesn't matter all that much.  I 
might end up changing that later. 

Anyway, i'm seeing {{driver-35}} perform at about 70% of {{master}} in terms of 
average rps. So, it's not miserable, but there's a noticeable gap there.

> Use one connection per request for Java client
> ----------------------------------------------
>
>                 Key: TINKERPOP-2205
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2205
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: driver
>    Affects Versions: 3.3.6
>            Reporter: Divij Vaidya
>            Assignee: Stephen Mallette
>            Priority: Major
>              Labels: deprecation
>
> This issue is a tracking item for the conversation in the mailing list 
> [[1]|https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E]
>  which highlights multiple problems and shortcomings in the existing Java 
> client and proposes a design change in the client connection pooling to 
> address the same. More specifically, the problems addressed are as follows:
>  # Difficulty in configuring the client for optimum performance.
>  # Undocumented dependency of configuration parameters on each other.
>  # A bad request can impact other requests on the same channel.
>  # Host is marked as dead even if it is busy serving requests.
>  # No way to free up server resources if the client has stopped consuming 
> results.
>  # No differentiation between retriable and non-retriable exceptions from the 
> application code.
>  # Keep alive is only sent when a query is executing, which means that a 
> connection open for a very long time with no query being sent will be closed 
> by the server.
>  # Race condition if the server response reaches before result queue has been 
> registered.
>  # Unpredictable behaviour if the server sends an exception followed by a 
> genuine response for the same request.
>  # A concurrent hash map (tracking pending requests) is a point of contention 
> amongst threads.
> [1]https://lists.apache.org/thread.html/77728cb77d4eab90f15680595e653ffc6055b74db29cbd4dcd5f0339@%3Cdev.tinkerpop.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to