Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of wav100@gmail.com designates
 74.125.83.44 as permitted sender)
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=DjHLR91CEzf5RTJ4OJEb8Fq8c9r3tbzEXhHp+M6/eTaqb9PL975YhCxvCE5HpJ6uEc
         pMaRa6qN198ej3pa59X66OwThV3UZsjwLfqcFIAd7AcHLERXMmKp2ULL+U99WqgftBhw
         P+fmprcOvjCPU2bWZ2skAkUTLAt/FtTkuc84Y=
MIME-Version: 1.0
In-Reply-To: <AANLkTimpL475-DrecqZeBVs233H_-188KUGfDr7av9-=@mail.gmail.com>
References: <AANLkTinxE4GSiZJBLiskC-zoGFg7mCKT0=-m3jWuvv2h@mail.gmail.com>
	<AANLkTimpL475-DrecqZeBVs233H_-188KUGfDr7av9-=@mail.gmail.com>
Date: Tue, 19 Oct 2010 14:11:15 -0400
Message-ID: <AANLkTim035FDJ3sxNSW37HdBUabunfXEAFWcD6C6QqMz@mail.gmail.com>
Subject: Re: Read Latency
From: Wayne <wav100@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=000e0cd40650fef1730492fc37f2

--000e0cd40650fef1730492fc37f2
Content-Type: text/plain; charset=ISO-8859-1

Our problem is not that Python is slow, our problem is that getting data
from the Cassandra server is slow (while Cassandra itself is fast). Python
can handle the result data a lot faster that whatever is it passing through
now...

I guess to ask a specific question what right now is the fastest mechanism
in terms of latency to get data from Cassandra to a client application? I
assume it is Java? We would not use any higher level library and prefer to
go directly against thrift (whatever is the fastest method).  We can easily
write our own C++ layer but if C++ still has to go through Thrift and thrift
is our problem we have solved nothing. To us this appears much more as a
maturity/optimization problem in thrift than anything to do with language
benefits.

Given our entire wait is on a call to Thrift below I tend to think nothing
we do (in any language) will help except making optimizations to Thrift or
Avro?

Thanks for the help!

On Tue, Oct 19, 2010 at 1:18 PM, Jonathan Ellis <jbellis@gmail.com> wrote:

> I would expect C++ or Java to be substantially faster than Python.
> However, I note that Hector (and I believe Pelops) don't yet use the
> newest, fastest Thrift library.
>
> On Tue, Oct 19, 2010 at 8:21 AM, Wayne <wav100@gmail.com> wrote:
> > The changes seems to do the trick. We are down to about 1/2 of the
> original
> > quorum read performance. I did not see any more errors.
> >
> > More than 3 seconds on the client side is still not acceptable to us. We
> > need the data in Python, but would we be better off going through Java or
> > something else to increase performance? All three seconds are taken up in
> > Thrift itself (fastbinary.decode_binary(self, iprot.trans,
> (self.__class__,
> > self.thrift_spec))) so I am not sure what other options we have.
> >
> > Thanks for your help.
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>

--000e0cd40650fef1730492fc37f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Our problem is not that Python is slow, our problem is that getting data fr=
om the Cassandra server is slow (while Cassandra itself is fast). Python ca=
n handle the result data a lot faster that whatever is it passing through n=
ow...<br>
<br>I guess to ask a specific question what right now is the fastest mechan=
ism in terms of latency to get data from Cassandra to a client application?=
 I assume it is Java? We would not use any higher level library and prefer =
to go directly against thrift (whatever is the fastest method).=A0 We can e=
asily write our own C++ layer but if C++ still has to go through Thrift and=
 thrift is our problem we have solved nothing. To us this appears much more=
 as a maturity/optimization problem in thrift than anything to do with lang=
uage benefits. <br>
<br>Given our entire wait is on a call to Thrift below I tend to think noth=
ing we do (in any language) will help except making optimizations to Thrift=
 or Avro?<br><br>Thanks for the help!<br><br><div class=3D"gmail_quote">On =
Tue, Oct 19, 2010 at 1:18 PM, Jonathan Ellis <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jbellis@gmail.com">jbellis@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I would expect C+=
+ or Java to be substantially faster than Python.<br>
However, I note that Hector (and I believe Pelops) don&#39;t yet use the<br=
>
newest, fastest Thrift library.<br>
<div><div></div><div class=3D"h5"><br>
On Tue, Oct 19, 2010 at 8:21 AM, Wayne &lt;<a href=3D"mailto:wav100@gmail.c=
om">wav100@gmail.com</a>&gt; wrote:<br>
&gt; The changes seems to do the trick. We are down to about 1/2 of the ori=
ginal<br>
&gt; quorum read performance. I did not see any more errors.<br>
&gt;<br>
&gt; More than 3 seconds on the client side is still not acceptable to us. =
We<br>
&gt; need the data in Python, but would we be better off going through Java=
 or<br>
&gt; something else to increase performance? All three seconds are taken up=
 in<br>
&gt; Thrift itself (fastbinary.decode_binary(self, iprot.trans, (self.__cla=
ss__,<br>
&gt; self.thrift_spec))) so I am not sure what other options we have.<br>
&gt;<br>
&gt; Thanks for your help.<br>
&gt;<br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class=3D"h5">Jonathan Ellis<br>
Project Chair, Apache Cassandra<br>
co-founder of Riptano, the source for professional Cassandra support<br>
<a href=3D"http://riptano.com" target=3D"_blank">http://riptano.com</a><br>
</div></div></blockquote></div><br>

--000e0cd40650fef1730492fc37f2--