Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 21 Oct 2015 07:44:27 +0000 (UTC)
From: "Hiroshi Ikeda (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12896012.1443077533000.15103.1445413467754@Atlassian.JIRA>
In-Reply-To: <JIRA.12896012.1443077533000@Atlassian.JIRA>
References: <JIRA.12896012.1443077533000@Atlassian.JIRA>
 <JIRA.12896012.1443077533604@arcas>
Subject: [jira] [Commented] (HBASE-14479) Apply the Leader/Followers pattern
 to RpcServer's Reader
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hiroshi Ikeda commented on HBASE-14479:
---------------------------------------

{quote}
I could experiment with removing queues to see if it buys us throughput.
{quote}

Some of tasks take a time to execute, and before dispatching a tasks within the same thread, we should do key.interestOps(OP_READ) so that the selector resumes receiving data from the corresponding connection, otherwise parallelized scans in Phoenix or other cheat might reduce performance. Even if so, Support fairness across parallelized scans (HBASE-12790) becomes difficult for scans coming from the same TCP stream.

> Apply the Leader/Followers pattern to RpcServer's Reader
> --------------------------------------------------------
>
>                 Key: HBASE-14479
>                 URL: https://issues.apache.org/jira/browse/HBASE-14479
>             Project: HBase
>          Issue Type: Improvement
>          Components: IPC/RPC, Performance
>            Reporter: Hiroshi Ikeda
>            Assignee: Hiroshi Ikeda
>            Priority: Minor
>         Attachments: HBASE-14479-V2 (1).patch, HBASE-14479-V2.patch, HBASE-14479-V2.patch, HBASE-14479.patch, gc.png, gets.png, io.png, median.png
>
>
> {{RpcServer}} uses multiple selectors to read data for load distribution, but the distribution is just done by round-robin. It is uncertain, especially for long run, whether load is equally divided and resources are used without being wasted.
> Moreover, multiple selectors may cause excessive context switches which give priority to low latency (while we just add the requests to queues), and it is possible to reduce throughput of the whole server.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)