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 8DDBC1035B for ; Mon, 6 May 2013 01:32:00 +0000 (UTC) Received: (qmail 83841 invoked by uid 500); 6 May 2013 01:31:58 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 83784 invoked by uid 500); 6 May 2013 01:31:58 -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 83776 invoked by uid 99); 6 May 2013 01:31:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 May 2013 01:31:57 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of derek@fyrie.net designates 72.14.182.177 as permitted sender) Received: from [72.14.182.177] (HELO sikozu.fyrie.net) (72.14.182.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 May 2013 01:31:53 +0000 Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sikozu.fyrie.net with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.76) (envelope-from ) id 1UZAH6-0000cv-7F for user@cassandra.apache.org; Sun, 05 May 2013 19:31:32 -0600 Received: by mail-ob0-f175.google.com with SMTP id wd20so1570966obb.20 for ; Sun, 05 May 2013 18:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=NCAq+IxKg6dEBHTD5qwad8weBD6pKceISH8LbDd7MME=; b=G1/rOaMx8a8sI5Z8NGKMEGR3eLsBFGG6VxAV3q269D1g+8eImtkUKz0oetdVCnydro w6D4GQ3EzViiTeXb/YYMt2V1wHtFFGGCNX4n6wI2Gz3jYDKch2hHRQJqWrJL4g/NIP3f Ao2K5RDDXTth9MD64IaVxSrez0Hy4PxWHiShtSZD/Mx120pQVv4HiIZ13R40cafmpgDS Kzso1HIOl65FglYGgZxzwgcyfAmc3rtnTbCHJ0XOBmtADvyRbJ9RI2CoghSomqcOwjkG 3GtWyrgPUztgrKtu2RpUktZLPbxDQ9VEjRzrXGQnYBFKXG0JEqUbdNafbX1y5DrOlbft MtlQ== MIME-Version: 1.0 X-Received: by 10.60.42.197 with SMTP id q5mr2227763oel.37.1367803886876; Sun, 05 May 2013 18:31:26 -0700 (PDT) Received: by 10.76.86.137 with HTTP; Sun, 5 May 2013 18:31:26 -0700 (PDT) In-Reply-To: References: <7DAD9716-2AE8-436D-BA59-B61FD397BFC5@me.com> <2212481367737425@web18d.yandex.ru> Date: Sun, 5 May 2013 19:31:26 -0600 Message-ID: Subject: Re: hector or astyanax From: Derek Williams To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c20dceccc29c04dc02a812 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c20dceccc29c04dc02a812 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I haven't done any performance testing with Cassandra 1.2, I was only giving possible reasons why the datastax binary driver might be faster. I have seen much better performance and reliability under heavy load in our internal rest services when switching from HTTP to SPDY. Possible reasons could be less sockets reads with more data per read which increases throughput, and it's easier to configure optimally. And it could very well be that the datastax binary driver is slower than a thrift client, I haven't benchmarked it. Even so, that doesn't mean a driver that used Cassandra's binary protocol couldn't be made to run faster. I look forward to the opportunity to give it a try once we do move to 1.2. On Sun, May 5, 2013 at 6:39 PM, Edward Capriolo wrot= e: > I am aware of no benchmark that shows the binary driver to be faster then > thrift. Yes. Theoretically a driver that with multiplex *should be* faste= r > in *some* cases. However I have never seen any evidence to back up this > theory anecdotal or otherwise. > > In fact.... > https://github.com/pchalamet/cassandra-sharp/pull/24 > > > On Sun, May 5, 2013 at 4:09 PM, Derek Williams wrote: > >> The binary protocol is able to multiplex multiple requests using a singl= e >> connection, which can lead to much better performance (similar to HTTP v= s >> SPDY). This is without comparing the performance of thrift vs binary >> protocol, which I assume the binary protocol would be faster since it is >> specialized for cassandra requests. >> >> >> On Sun, May 5, 2013 at 12:14 PM, Renato Marroqu=C3=ADn Mogrovejo < >> renatoj.marroquin@gmail.com> wrote: >> >>> Hey Shamim, >>> >>> Why do you say that Java-Driver has better performance over Hector or >>> Astyanax? Is there any reasons for this? >>> Thanks. >>> >>> >>> Renato M. >>> >>> 2013/5/5 Shamim : >>> > Hi, >>> > Astyanax is just a refactoring of Hector and implements a few commo= n >>> cassandra use cases. Very easy to use api. In Astyanax you will found a= ll >>> the functions from hector. For better performance you can also check >>> datastax java driver https://github.com/datastax/java-driver. >>> > >>> > There are another lightweight client from twitter >>> https://github.com/twitter/cassie >>> > >>> > -- >>> > Best regards >>> > Shamim A. >>> > >>> > 05.05.2013, 05:30, "=E6=9D=8E =E6=99=97" : >>> >> hello=EF=BC=8C >>> >> i want to know which cassandra client is better=EF=BC=9F >>> >> and what are their advantages and disadvantages=EF=BC=9F >>> >> >>> >> thanks >>> >> >> >> >> -- >> Derek Williams >> > > --=20 Derek Williams --001a11c20dceccc29c04dc02a812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I haven't done any performance testing with Cassand= ra 1.2, I was only giving possible reasons why the datastax binary driver m= ight be faster. I have seen much better performance and reliability under h= eavy load in our internal rest services when switching from HTTP to SPDY. P= ossible reasons could be less sockets reads with more data per read which i= ncreases throughput, and it's easier to configure optimally.

And it could very well be that the datastax binary driver is slower = than a thrift client, I haven't benchmarked it. Even so, that doesn'= ;t mean a driver that used Cassandra's binary protocol couldn't be = made to run faster. I look forward to the opportunity to give it a try once= we do move to 1.2.



On Sun,= May 5, 2013 at 6:39 PM, Edward Capriolo <edlinuxguru@gmail.com>= ; wrote:
I am aware of no benchmark = that shows the binary driver to be faster then thrift. Yes. Theoretically a= driver that with multiplex *should be* faster in *some* cases. However I h= ave never seen any evidence to back up this theory anecdotal or otherwise. =

In fact....
https://github.com/pchalamet/cassandra-sharp/pul= l/24


On Sun, May 5, 2013 at 4:09 PM, Derek Williams <derek@fyr= ie.net> wrote:
The binary protocol is able to multiplex multiple requ= ests using a single connection, which can lead to much better performance (= similar to HTTP vs SPDY). This is without comparing the performance of thri= ft vs binary protocol, which I assume the binary protocol would be faster s= ince it is specialized for cassandra requests.


On Sun, May 5= , 2013 at 12:14 PM, Renato Marroqu=C3=ADn Mogrovejo <<= a href=3D"mailto:renatoj.marroquin@gmail.com" target=3D"_blank">renatoj.mar= roquin@gmail.com> wrote:
Hey Shamim,

Why do you say that Java-Driver has better performance over Hector or
Astyanax? Is there any reasons for this?
Thanks.


Renato M.

2013/5/5 Shamim <s= recon@yandex.ru>:
> Hi,
> =C2=A0 Astyanax is just a refactoring of Hector and implements a few c= ommon cassandra use cases. Very easy to use api. In Astyanax you will found= all the functions from hector. For better performance you can also check d= atastax java driver https://github.com/datastax/java-driver.
>
> There are another lightweight client from twitter https://github.com/twitter/cass= ie
>
> --
> Best regards
> =C2=A0 Shamim A.
>
> 05.05.2013, 05:30, "=E6=9D=8E =E6=99=97" <bjbylh@me.com>:
>> hello=EF=BC=8C
>> i want to know which cassandra client is better=EF=BC=9F
>> and what are their advantages and disadvantages=EF=BC=9F
>>
>> thanks
=


--
Derek Williams




--
Derek W= illiams
--001a11c20dceccc29c04dc02a812--