[ 
https://issues.apache.org/jira/browse/ACCUMULO-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Reply via email to