accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3477) Evaluate use of TThreadedSelectorServer
Date Tue, 16 Feb 2016 15:17:18 GMT


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:
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: master, tserver
>            Reporter: Josh Elser
>             Fix For: 1.8.0
> I re-read 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

View raw message