Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 27275 invoked from network); 19 Jul 2010 17:52:20 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Jul 2010 17:52:20 -0000 Received: (qmail 85052 invoked by uid 500); 19 Jul 2010 17:52:18 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 84923 invoked by uid 500); 19 Jul 2010 17:52:18 -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 84915 invoked by uid 99); 19 Jul 2010 17:52:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jul 2010 17:52:18 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Jul 2010 17:52:09 +0000 Received: by wwb39 with SMTP id 39so520594wwb.25 for ; Mon, 19 Jul 2010 10:51:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.12.148 with SMTP id 20mr4207096wez.111.1279561907622; Mon, 19 Jul 2010 10:51:47 -0700 (PDT) Sender: scode@scode.org Received: by 10.216.234.18 with HTTP; Mon, 19 Jul 2010 10:51:47 -0700 (PDT) X-Originating-IP: [213.114.156.79] In-Reply-To: References: <4780D37D-47DE-4A28-8DE7-59B119555537@clearspring.com> <1279554146.314124203@192.168.2.227> <1279560166.856519322@192.168.2.227> Date: Mon, 19 Jul 2010 19:51:47 +0200 X-Google-Sender-Auth: wCnwPFSw2D58qKUntcLt1APSuak Message-ID: Subject: Re: Cassandra benchmarking on Rackspace Cloud From: Peter Schuller To: user@cassandra.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org >> One with 50 threads; it is remote from the cluster but within the same >> DC in both cases. I also run the test with multiple clients and saw >> similar results when summing the reqs/sec. > > Multiple client processes, or multiple client machines? In particular, note that the way CPython works, if you're CPU bound across many threads, you're constantly hitting the worst possible scenario with respect to wasting CPU cycles on multiple cores (due to the extremely contended GIL). While I'd still expect to see an increase in throughput from running multiple separate processes on the same (multi-core) machine, I really wouldn't be too sure. Even with supposedly idle CPU you may still be bottlenecking on the client depending on scheduling decisions in the kernel. -- / Peter Schuller