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

Lars Hofhansl commented on HDFS-6735:
-------------------------------------

As described in HDFS-6698, the potential performance gains for something like 
HBase are substantial.

I agree it's better to keep LocatedBlocks as not threadsafe and require called 
to lock accordingly.
I've not see fetchAt in a hot path (at least not from HBase usage patterns).
seek + read (non positional) cannot be done concurrently, agreed. pread should 
be possible, though.

How should we continue to move on this? Seems important. :)

Also open to suggestions about how to fix things in HBase (see last comment in 
HDFS-6698, about how HBase handles things and how limited concurrency "within" 
an InputStream is an issue).


> A minor optimization to avoid pread() be blocked by read() inside the same 
> DFSInputStream
> -----------------------------------------------------------------------------------------
>
>                 Key: HDFS-6735
>                 URL: https://issues.apache.org/jira/browse/HDFS-6735
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: hdfs-client
>    Affects Versions: 3.0.0
>            Reporter: Liang Xie
>            Assignee: Liang Xie
>         Attachments: HDFS-6735-v2.txt, HDFS-6735.txt
>
>
> In current DFSInputStream impl, there're a couple of coarser-grained locks in 
> read/pread path, and it has became a HBase read latency pain point so far. In 
> HDFS-6698, i made a minor patch against the first encourtered lock, around 
> getFileLength, in deed, after reading code and testing, it shows still other 
> locks we could improve.
> In this jira, i'll make a patch against other locks, and a simple test case 
> to show the issue and the improved result.
> This is important for HBase application, since in current HFile read path, we 
> issue all read()/pread() requests in the same DFSInputStream for one HFile. 
> (Multi streams solution is another story i had a plan to do, but probably 
> will take more time than i expected)



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

Reply via email to