Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 23 Apr 2017 06:49:04 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13066139.1492929885000.28012.1492930144213@Atlassian.JIRA>
In-Reply-To: <JIRA.13066139.1492929885000@Atlassian.JIRA>
References: <JIRA.13066139.1492929885000@Atlassian.JIRA> <JIRA.13066139.1492929885577@jira-lw-us.apache.org>
Subject: [jira] [Commented] (COMPRESS-388) Improve concurrent reads from
 ZipFile
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 23 Apr 2017 06:49:11 -0000


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

ASF GitHub Bot commented on COMPRESS-388:
-----------------------------------------

GitHub user kvr000 opened a pull request:

    https://github.com/apache/commons-compress/pull/21

    COMPRESS-388: Fix concurrent reads performance

    Ticket: https://issues.apache.org/jira/browse/COMPRESS-388
    
    Concurrent reads on the ZipFile archive is terribly slow on multiprocessor systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples for example.
    
    The cause is the use of synchronized blocks to access the underlying file channel. This may be required for generic SeekableByteChannel but most commonly there is FileChannel implementation which supports lock-free reading from any position (i.e. using pread/pwrite system calls or their equivalent).
    
    With the fix the performance is about 10 times faster (on 4 CPU system, with more processor the difference should grow significantly).

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/kvr000/commons-compress feature/COMPRESS-388-concurrent-reads-performance-fix

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/commons-compress/pull/21.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #21
    
----
commit 3c8672db0a68dcd6b59c36abc3ec676b5af02f0a
Author: Zbynek Vyskovsky <kvr000@gmail.com>
Date:   2017-04-23T06:45:46Z

    COMPRESS-388: Fix concurrent reads performance

----


> Improve concurrent reads from ZipFile
> -------------------------------------
>
>                 Key: COMPRESS-388
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-388
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>    Affects Versions: 1.13
>         Environment: Any
>            Reporter: Zbynek Vyskovsky
>              Labels: patch, performance
>             Fix For: 1.14
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Concurrent reads on the ZipFile archive is terribly slow on multiprocessor systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples for example.
> The cause is the use of synchronized blocks to access the underlying file channel. This may be required for generic SeekableByteChannel but most commonly there is FileChannel implementation which supports lock-free reading from any position (i.e. using pread/pwrite system calls or their equivalent).
> With the fix the performance is about 10 times faster (on 4 CPU system, with more processor the difference should grow significantly).


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)