hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-1583) Improve backup-node sync performance by wrapping RPC parameters
Date Thu, 13 Jan 2011 20:16:47 GMT

    [ https://issues.apache.org/jira/browse/HDFS-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981455#action_12981455
] 

Doug Cutting commented on HDFS-1583:
------------------------------------

ObjectWritable might be used by applications and changing its format may be hard to do compatibly.
 But it would be relatively easy to switch RPC to use a different format.  So we might move
ObjectWritable's array i/o to protected methods, add a subclass with an optimized implementation
of these methods, then use that subclass in RPC in place of ObjectWritable.

> Improve backup-node sync performance by wrapping RPC parameters
> ---------------------------------------------------------------
>
>                 Key: HDFS-1583
>                 URL: https://issues.apache.org/jira/browse/HDFS-1583
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>            Reporter: Liyin Liang
>            Assignee: Liyin Liang
>             Fix For: 0.23.0
>
>         Attachments: HDFS-1583-1.patch, HDFS-1583-2.patch
>
>
> The journal edit records are sent by the active name-node to the backup-node with RPC:
> {code:}
>   public void journal(NamenodeRegistration registration,
>                       int jAction,
>                       int length,
>                       byte[] records) throws IOException;
> {code}
> During the name-node throughput benchmark, the size of byte array _records_ is around
*8000*.  Then the serialization and deserialization is time-consuming. I wrote a simple application
to test RPC with byte array parameter. When the size got to 8000, each RPC call need about
6 ms. While name-node sync 8k byte to local disk only need  0.3~0.4ms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message