accumulo-notifications mailing list archives

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


marco polo commented on ACCUMULO-3477:

I began using TThreadedSelectorServer this weekend for a similar use case and it works exceptionally

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:
>             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