[
https://issues.apache.org/jira/browse/HBASE-14479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378767#comment-15378767
]
Hiroshi Ikeda commented on HBASE-14479:
---------------------------------------
In order to reduce overhead of unnecessarily changing registrations, we should
postpone making the read flag on and delegating the leader to exclusive access
to the socket, until we realize we cannot construct a task even after
retrieving data from the socket. Additionally, we should retrieve data with a
off-heap buffer whose size is equal to or larger than the socket's native
buffer, for reducing overhead of native calls.
Of course retrieving all available tasks from a socket at a time causes memory
shortage and unfair execution as to connections. In order to prevent the
unfairness, we should queue at most one task per connection. That doesn't mean
that one connection cannot execute multiple tasks simultaneously; The
restriction is for queued tasks waiting execution. From a different viewpoint,
just before executing a task, we should delegate another follower to execute or
queue the next task or delegate the leader, as described above.
AdaptiveLifoCoDelCallQueue is not appropriate when clients can simultaneously
send multiple requests. Because it is not realistic to retrieve all requests,
the requests will be executed in available order when congestion. Moreover,
that requests will be unfairly executed prior to others because that are
retrieved later.
> 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, flamegraph-19152.svg,
> flamegraph-32667.svg, 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)
