Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1BDBF96FE for ; Mon, 13 Feb 2012 11:48:11 +0000 (UTC) Received: (qmail 18495 invoked by uid 500); 13 Feb 2012 11:48:08 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 18352 invoked by uid 500); 13 Feb 2012 11:48:07 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 18344 invoked by uid 99); 13 Feb 2012 11:48:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2012 11:48:07 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.149.67] (HELO na3sys009aog101.obsmtp.com) (74.125.149.67) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 13 Feb 2012 11:47:59 +0000 Received: from mail-lpp01m020-f182.google.com ([209.85.217.182]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTzj4V/moOY+D2XIFzSQRg4uxTJKHV2Fm@postini.com; Mon, 13 Feb 2012 03:47:38 PST Received: by mail-lpp01m020-f182.google.com with SMTP id gj3so2950165lbb.41 for ; Mon, 13 Feb 2012 03:47:35 -0800 (PST) Received: by 10.152.134.200 with SMTP id pm8mr11024869lab.34.1329133655112; Mon, 13 Feb 2012 03:47:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.26.199 with HTTP; Mon, 13 Feb 2012 03:47:15 -0800 (PST) From: Franc Carter Date: Mon, 13 Feb 2012 22:47:15 +1100 Message-ID: Subject: active/pending queue lengths To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=f46d042fde2e5f3a7c04b8d70b35 X-Gm-Message-State: ALoCoQmNglXAUoVsM0/rOi+S18/XP5cqvnevOFTBP9Dp64q74wMWdqHzNNBPSUDga1Xy+C356vL2 X-Virus-Checked: Checked by ClamAV on apache.org --f46d042fde2e5f3a7c04b8d70b35 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've been looking at tpstats as various test queries run and I noticed something I don't understand. I have a two node cluster with RF=2 on which I run 4 parallel queries, each job goes through a list of keys doing a multiget for 2 keys at a time. If two of the queries go to one node and the other two go to a different node then the pending queue on the node gets much longer than if they all go to the one node. I'm clearly missing something here as I would have expected the opposite cheers -- *Franc Carter* | Systems architect | Sirca Ltd franc.carter@sirca.org.au | www.sirca.org.au Tel: +61 2 9236 9118 Level 9, 80 Clarence St, Sydney NSW 2000 PO Box H58, Australia Square, Sydney NSW 1215 --f46d042fde2e5f3a7c04b8d70b35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

I've been looking at tpstats as v= arious test queries run and I noticed something I don't understand.

I have a two node cluster with RF=3D2 on which I run = 4 parallel queries, each job goes through a list of keys doing a multiget f= or 2 keys at a time. If two of the queries go to one node and the other two= go to a different node then the pending queue on the node gets much longer= than if they all go to the one node.

I'm clearly missing something here as I would = have expected the opposite

cheers

--

Franc Carter<= /b> |<= /span> Systems architect | Sirca Ltd

franc.carter@sirca.org.au=A0|=A0www.sirca.org.au

Tel:= =A0+61 2 9236 9118

Level 9, 80 Clarence St, Sydney=A0NSW 2000

PO Box H58, Australia Square, Sydney NSW 1215<= /span>


--f46d042fde2e5f3a7c04b8d70b35--