Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 21998 invoked from network); 16 Dec 2009 15:30:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Dec 2009 15:30:52 -0000 Received: (qmail 28604 invoked by uid 500); 16 Dec 2009 15:30:50 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 28139 invoked by uid 500); 16 Dec 2009 15:30:49 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 28014 invoked by uid 99); 16 Dec 2009 15:30:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2009 15:30:49 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of richiesgr@gmail.com designates 209.85.220.214 as permitted sender) Received: from [209.85.220.214] (HELO mail-fx0-f214.google.com) (209.85.220.214) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2009 15:30:44 +0000 Received: by fxm6 with SMTP id 6so1107565fxm.20 for ; Wed, 16 Dec 2009 07:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=QtvjE5DLjmpg91dLOOMaZZlplNlOa30bdwdSsbkwEyo=; b=esz2iZEOtG7oevpsmFPiE+54dRH8wwxx0ifqkNl4hM9kEGaAD3aj+nCOlOjX+KF1SU igwjt5b5rlOoPismEpSNP/PhIUZbpOHcnfvel+sZn5WFCvNxkH8aHpoOWMq0bluKg6NU 4b9o9jVjNc7SC9bnMaNO7AgOPBj8CMKRhs6TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=EC/l66/yRsvVr1T3HmIcvImfcR94MjLS5JF3lFDtL/x93xr34JLKSIu3KNti0pnwSI A4K6hxpqY6tndNMi8fnP3wd1dy8SoU2CdWTTXUnDnB/H5oDl6D46H4Y485Ka+epSyy6l T0mQkjfvDWvSbe6H2ORLzC+j46pobSm52BYEw= MIME-Version: 1.0 Received: by 10.239.143.212 with SMTP id l20mr114139hba.210.1260977423139; Wed, 16 Dec 2009 07:30:23 -0800 (PST) In-Reply-To: References: <468b21170912160606n64e1f780id3500758862eaddb@mail.gmail.com> Date: Wed, 16 Dec 2009 17:30:23 +0200 Message-ID: <468b21170912160730t13f0b551rb46c6db08721aff9@mail.gmail.com> Subject: Re: Question about Insert Time with multiple node From: Richard Grossman To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=001485f271e060459d047ada2fba --001485f271e060459d047ada2fba Content-Type: text/plain; charset=ISO-8859-1 I'm not using 50 thread but make it with 4 thread. I give 2 thread by server ip. So I insert using 2 thread on 1 machine and with 2 other on the second machine I need to add a lot of thread to be able to insert this data quickly enough. but for you it's logical this behavior ? On Wed, Dec 16, 2009 at 4:45 PM, Jonathan Ellis wrote: > Sounds like you are using a single thread, so the increased latency is > artificially reducing your numbers. Add more threads (stress.py uses > 50 by default) to get more throughput. (Also true even for a single > node, but more noticable when you add network overhead to the > cluster.) > > -Jonathan > > On Wed, Dec 16, 2009 at 8:06 AM, Richard Grossman > wrote: > > Hi > > > > I think someone ask already similar but can't find where. > > > > On 1 machine standalone I insert data I get ~850 rows / second > > On another machine I make exactly the same operation I get ~900/1000 rows > / > > second > > > > Now I remove all the data from the 2 machines. Take exactly the same > > storage-conf.xml but just add seed in both file nothing else. > > Make the insert I get ~90 rows / second. > > > > Someone have an idea why the performance could fall sharply like this. Or > > simply give a hint what or where to check why it's happend > > I've already checked network problem the 2 machines are identical. > > > > Thanks. > > > > > > > --001485f271e060459d047ada2fba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not using 50 thread but make it with 4 thread.
= I give 2 thread by server ip. So I insert using 2 thread on 1 machine and w= ith 2 other on the second machine

I need to add a lot of thread to b= e able to insert this data quickly enough.

but for you it's logical this behavior ?



On Wed, Dec 16, 2009 at 4:45 PM, Jonathan Ellis <jbellis@gmail.com>= wrote:
Sounds like you a= re using a single thread, so the increased latency is
artificially reducing your numbers. =A0Add more threads (stress.py uses
50 by default) to get more throughput. (Also true even for a single
node, but more noticable when you add network overhead to the
cluster.)

-Jonathan

On Wed, Dec 16, 2009 at 8:06 AM, Richard Grossman <richiesgr@gmail.com> wrote:
> Hi
>
> I think someone ask already similar but can't find where.
>
> On 1 machine standalone I insert data I get ~850 rows / second
> On another machine I make exactly the same operation I get ~900/1000 r= ows /
> second
>
> Now I remove all the data from the 2 machines. Take exactly the same > storage-conf.xml but just add seed in both file nothing else.
> Make the insert I get ~90 rows / second.
>
> Someone have an idea why the performance could fall sharply like this.= Or
> simply give a hint what or where to check why it's happend
> I've already checked network problem the 2 machines are identical.=
>
> Thanks.
>
>
>

--001485f271e060459d047ada2fba--