Return-Path: 
 <commits-return-140160-apmail-cassandra-commits-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-commits-archive@www.apache.org
Delivered-To: apmail-cassandra-commits-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 2C48618928
	for <apmail-cassandra-commits-archive@www.apache.org>;
 Tue,  4 Aug 2015 14:41:08 +0000 (UTC)
Received: (qmail 69524 invoked by uid 500); 4 Aug 2015 14:41:08 -0000
Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org
Received: (qmail 69491 invoked by uid 500); 4 Aug 2015 14:41:08 -0000
Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@cassandra.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@cassandra.apache.org>
List-Post: <mailto:commits@cassandra.apache.org>
List-Id: <commits.cassandra.apache.org>
Reply-To: dev@cassandra.apache.org
Delivered-To: mailing list commits@cassandra.apache.org
Received: (qmail 69475 invoked by uid 99); 4 Aug 2015 14:41:07 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Aug 2015 14:41:07 +0000
Date: Tue, 4 Aug 2015 14:41:07 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12767804.1421347533000.367421.1438699267904@Atlassian.JIRA>
In-Reply-To: <JIRA.12767804.1421347533000@Atlassian.JIRA>
References: <JIRA.12767804.1421347533000@Atlassian.JIRA>
 <JIRA.12767804.1421347533506@arcas>
Subject: [jira] [Commented] (CASSANDRA-8630) Faster sequential IO (on
 compaction, streaming, etc)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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

Benedict commented on CASSANDRA-8630:
-------------------------------------

My expectation was that we would extract the existing "is sufficient remaining?" check, and use this to drive a decision. It doesn't really matter what we do inside this block, because that is executed infrequently. I would have a {{long readBytesSlowly(int count)}} method, which we downcast the result to whatever we have actually read. That method would call {{readNext()}} as necessary, and would be prevented from being inlined. But that's just how I would do it, since I prefer not to incur complexity when we know the cost will be amortized away, nor inline that method and inflate our code size for the same reason. 

I don't think it matters _terribly_, though, and if you or [~stefania] have a strong opinion I won't stand in the way (unless it happens to trigger a strong and unexpected anti-opinion)

> Faster sequential IO (on compaction, streaming, etc)
> ----------------------------------------------------
>
>                 Key: CASSANDRA-8630
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8630
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core, Tools
>            Reporter: Oleg Anastasyev
>            Assignee: Stefania
>              Labels: compaction, performance
>             Fix For: 3.x
>
>         Attachments: 8630-FasterSequencialReadsAndWrites.txt, cpu_load.png, flight_recorder_001_files.tar.gz
>
>
> When node is doing a lot of sequencial IO (streaming, compacting, etc) a lot of CPU is lost in calls to RAF's int read() and DataOutputStream's write(int).
> This is because default implementations of readShort,readLong, etc as well as their matching write* are implemented with numerous calls of byte by byte read and write. 
> This makes a lot of syscalls as well.
> A quick microbench shows than just reimplementation of these methods in either way gives 8x speed increase.
> A patch attached implements RandomAccessReader.read<Type> and SequencialWriter.write<Type> methods in more efficient way.
> I also eliminated some extra byte copies in CompositeType.split and ColumnNameHelper.maxComponents, which were on my profiler's hotspot method list during tests.
> A stress tests on my laptop show that this patch makes compaction 25-30% faster  on uncompressed sstables and 15% faster for compressed ones.
> A deployment to production shows much less CPU load for compaction. 
> (I attached a cpu load graph from one of our production, orange is niced CPU load - i.e. compaction; yellow is user - i.e. not compaction related tasks)



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