From user-return-44052-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Sun Dec 7 08:59:39 2014 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 46B80100C9 for ; Sun, 7 Dec 2014 08:59:39 +0000 (UTC) Received: (qmail 65671 invoked by uid 500); 7 Dec 2014 08:59:36 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 65623 invoked by uid 500); 7 Dec 2014 08:59:35 -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 65613 invoked by uid 99); 7 Dec 2014 08:59:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Dec 2014 08:59:35 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kongjialin92@gmail.com designates 209.85.220.46 as permitted sender) Received: from [209.85.220.46] (HELO mail-pa0-f46.google.com) (209.85.220.46) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Dec 2014 08:59:30 +0000 Received: by mail-pa0-f46.google.com with SMTP id lj1so3336307pab.5 for ; Sun, 07 Dec 2014 00:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=p6xkqVxN682TbRRO2gVSVaOu03gQ93zGtDqiB+uvFxI=; b=pf1k6OIAwd6xx0RPoUQHV2k6ghwLM5JnwMmTdQwlicJhVNnAAfrmm30GtyG4wVixHu 3f5c9tPsARoKxa2Ety+k19YqGqmxA5ziby05dGoa57LeTmsR2jWhxbBzMUFubw9d9OsV WXysvCTZIQQPc7+bfqgu+vcnY5y7oWc95c9L5RdysRV8SXwovCIEFhycLW4hyAsEVRfy +WiCemCDsWgaBuyp2HNM9SY5OyFbqtCFBAG1SGf9m77Ump9WP2hPVhPHeMgm2TmgRr2r oVletOGbzjjB9a9moFPbPZPMjkGmYbOoSPEpNBckq9mEjoLg79c6cDbhkgorAYzrkHsi yGkw== X-Received: by 10.70.37.4 with SMTP id u4mr10620782pdj.3.1417942750003; Sun, 07 Dec 2014 00:59:10 -0800 (PST) Received: from kongPC ([2001:da8:215:809:802b:d547:4d0e:f614]) by mx.google.com with ESMTPSA id hk9sm23257077pdb.47.2014.12.07.00.59.06 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 07 Dec 2014 00:59:09 -0800 (PST) From: "kong" To: Subject: Could ring cache really improve performance in Cassandra? Date: Sun, 7 Dec 2014 16:59:18 +0800 Message-ID: <00ae01d011fc$19d0f5e0$4d72e1a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01D0123F.27F6CDF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdAR+0xgKWXDxT03Sdufi1pcQNWgWw== Content-Language: zh-cn X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. ------=_NextPart_000_00AF_01D0123F.27F6CDF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I'm doing stress test on Cassandra. And I learn that using ring cache can improve the performance because the client requests can directly go to the target Cassandra server and the coordinator Cassandra node is the desired target node. In this way, there is no need for coordinator node to route the client requests to the target node, and maybe we can get the linear performance increment. However, in my stress test on an Amazon EC2 cluster, the test results are weird. Seems that there's no performance improvement after using ring cache. Could anyone help me explain this results? (Also, I think the results of test without ring cache is weird, because there's no linear increment on QPS when new nodes are added. I need help on explaining this, too). The results are as follows: INSERT(write): Node count Replication factor QPS(No ring cache) QPS(ring cache) 1 1 18687 20195 2 1 20793 26403 2 2 22498 21263 4 1 28348 30010 4 3 28631 24413 SELECT(read): Node count Replication factor QPS(No ring cache) QPS(ring cache) 1 1 24498 22802 2 1 28219 27030 2 2 35383 36674 4 1 34648 28347 4 3 52932 52590 Thank you very much, Joy ------=_NextPart_000_00AF_01D0123F.27F6CDF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I'm doing stress test on Cassandra. = And I learn that using ring cache can improve the performance because = the client requests can directly go to the target Cassandra server and = the coordinator Cassandra node is the desired target node. In this way, = there is no need for coordinator node to route the client requests to = the target node, and maybe we can get the linear performance = increment.

 

However, in my stress test on an Amazon EC2 cluster, the = test results are weird. Seems that there's no performance improvement = after using ring cache. Could anyone help me explain this results? = (Also, I think the results of test without ring cache is weird, because = there's no linear increment on QPS when new nodes are added. I need help = on explaining this, too). The results are as = follows:

 

INSERT(write):

Node = count

Repli= cation factor

QPS(N= o ring cache)

QPS(r= ing cache)

1

1

18687=

20195=

2

1

20793=

26403=

2

2

22498=

21263=

4

1

28348=

30010=

4

3

28631=

24413=

 

SELECT(read):

Node = count

Repli= cation factor

QPS(N= o ring cache)

QPS(r= ing cache)

1

1

24498=

22802=

2

1

28219=

27030=

2

2

35383=

36674=

4

1

34648=

28347=

4

3

52932=

52590=

 

 

Thank you very much,

Joy

------=_NextPart_000_00AF_01D0123F.27F6CDF0--