[jira] [Commented] (ACCUMULO-3477) Evaluate use of TThreadedSelectorServer
[
https://issues.apache.org/jira/browse/ACCUMULO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148783#comment-15148783
]
Josh Elser commented on ACCUMULO-3477:
--
bq. What worked really well was extending TThreadedSelectorServer, creating
threads for ops I knew would be fast, and leaving things like a "startScan" or
a "continue(Multi)Scan" handler to the thread pool. It required more coupling
of the server to the processor/handler, but ultimately worked really well.
Oh, cool. Thanks for sharing, [~phrocker]. I think coupling the processor impl
to the server is kind of required for such an optimization (since we're
essentially making decisions on how to run an RPC given the application-level
characteristics of that RPC). Do you have any tangible numbers as to how well
it worked, or was that just more "feeling"? Any thoughts on how we could
measure the improvement of such a change?
> Evaluate use of TThreadedSelectorServer
> ---
>
> Key: ACCUMULO-3477
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3477
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Josh Elser
> Fix For: 1.8.0
>
>
> I re-read
> https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared today,
> specifically the section on thshaserver vs tthreadedselectorserver.
> {quote}
> TThreadedSelectorServer performs better than THsHaServer when the network io
> is the bottleneck
> {quote}
> This made me think that in read-heavy environments, we may benefit from using
> the TThreadedSelectorServer instead of the THsHaServer. I know from previous
> experiments that we can spend a significant amount of time for a query just
> sending bytes over the wire from server(s) to a client. Improving this case
> may have benefit.
> Like THsHaServer, TThreadedSelectorServer relies on the TFramedTransport, so
> this is only relevant for non-SSL and non-SASL cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3477) Evaluate use of TThreadedSelectorServer
[
https://issues.apache.org/jira/browse/ACCUMULO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148554#comment-15148554
]
marco polo commented on ACCUMULO-3477:
--
I began using TThreadedSelectorServer this weekend for a similar use case and
it works exceptionally well.
What worked really well was extending TThreadedSelectorServer, creating threads
for ops I knew would be fast, and leaving things like a "startScan" or a
"continue(Multi)Scan" handler to the thread pool. It required more coupling of
the server to the processor/handler, but ultimately worked really well.
> Evaluate use of TThreadedSelectorServer
> ---
>
> Key: ACCUMULO-3477
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3477
> Project: Accumulo
> Issue Type: New Feature
> Components: master, tserver
>Reporter: Josh Elser
> Fix For: 1.8.0
>
>
> I re-read
> https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared today,
> specifically the section on thshaserver vs tthreadedselectorserver.
> {quote}
> TThreadedSelectorServer performs better than THsHaServer when the network io
> is the bottleneck
> {quote}
> This made me think that in read-heavy environments, we may benefit from using
> the TThreadedSelectorServer instead of the THsHaServer. I know from previous
> experiments that we can spend a significant amount of time for a query just
> sending bytes over the wire from server(s) to a client. Improving this case
> may have benefit.
> Like THsHaServer, TThreadedSelectorServer relies on the TFramedTransport, so
> this is only relevant for non-SSL and non-SASL cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3477) Evaluate use of TThreadedSelectorServer
[
https://issues.apache.org/jira/browse/ACCUMULO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275968#comment-14275968
]
Josh Elser commented on ACCUMULO-3477:
--
Left this assigned to myself because I'd like to work on it, but if someone has
cycles before I do to look at it, please feel free to reassign it to yourself
(or ask and I'll assign it if you don't have karma).
Evaluate use of TThreadedSelectorServer
---
Key: ACCUMULO-3477
URL: https://issues.apache.org/jira/browse/ACCUMULO-3477
Project: Accumulo
Issue Type: New Feature
Components: master, tserver
Reporter: Josh Elser
Assignee: Josh Elser
Fix For: 1.7.0
I re-read
https://github.com/m1ch1/mapkeeper/wiki/Thrift-Java-Servers-Compared today,
specifically the section on thshaserver vs tthreadedselectorserver.
{quote}
TThreadedSelectorServer performs better than THsHaServer when the network io
is the bottleneck
{quote}
This made me think that in read-heavy environments, we may benefit from using
the TThreadedSelectorServer instead of the THsHaServer. I know from previous
experiments that we can spend a significant amount of time for a query just
sending bytes over the wire from server(s) to a client. Improving this case
may have benefit.
Like THsHaServer, TThreadedSelectorServer relies on the TFramedTransport, so
this is only relevant for non-SSL and non-SASL cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
