Carlos Alvarez gmail.com> writes:
>
> On Sat, Apr 24, 2010 at 10:59 PM, Jonathan Ellis gmail.com>
wrote:
> > No, Framed is totally different.
> You are right. Seeing both, the java and c# thrift code, I think that
> there is no need to use other transport than TSocket in Java because
> it see
On Sat, Apr 24, 2010 at 10:59 PM, Jonathan Ellis wrote:
> No, Framed is totally different.
You are right. Seeing both, the java and c# thrift code, I think that
there is no need to use other transport than TSocket in Java because
it seems to be using buffered stream in the TSocket implementation.
On Sat, Apr 24, 2010 at 7:17 PM, Carlos Alvarez wrote:
> On Sat, Apr 24, 2010 at 8:00 PM, Joost Ouwerkerk wrote:
>> TBufferedTransport seems to be missing from the Java library bundled with
>> cassandra-bin (0.6.1)...
>
> I think is TFramedTransport in Java.
No, Framed is totally different.
> B
On Sat, Apr 24, 2010 at 8:00 PM, Joost Ouwerkerk wrote:
> TBufferedTransport seems to be missing from the Java library bundled with
> cassandra-bin (0.6.1)...
I think is TFramedTransport in Java.
BTW, I ran the test and I saw enomous improvement in performance (a
1/30 of the original time).
Don
TBufferedTransport seems to be missing from the Java library bundled with
cassandra-bin (0.6.1)...
On Sat, Apr 24, 2010 at 5:54 PM, Miguel Verde wrote:
> Yes, one should use either the TBufferedTransport or TFramedTransport in
> Java for performance reasons. These are analogous to the C# Socket c
Yes, one should use either the TBufferedTransport or TFramedTransport
in Java for performance reasons. These are analogous to the C# Socket
classes and you should see a performance improvement from buffering.
On Apr 24, 2010, at 5:31 PM, Joost Ouwerkerk
wrote:
Is this something that al
Is this something that also needs to be managed in Java? In most examples
I've seen, connections are created like this:
TSocket socket = new TSocket(location, thriftport)
TBinaryProtocol binaryProtocol = new
TBinaryProtocol(socket, false, false);
Cassandra.Clien
On Fri, Apr 23, 2010 at 4:29 PM, Heath Oderman wrote:
> Really interesting find.
> After Jonathan E. suggested py_stress and it seemed clear the problem was in
> my .net client I spent a few days debugging the client in detail.
> I ended up changing my CassandraContext instantiation to use a
>
Nice detective work! Good to know what was causing that. Thanks!
On Fri, Apr 23, 2010 at 2:29 PM, Heath Oderman wrote:
> Really interesting find.
> After Jonathan E. suggested py_stress and it seemed clear the problem was in
> my .net client I spent a few days debugging the client in detail.
>
Really interesting find.
After Jonathan E. suggested py_stress and it seemed clear the problem was in
my .net client I spent a few days debugging the client in detail.
I ended up changing my CassandraContext instantiation to use a
TBuffferedProtocol(TSocket) instead of a
TSoc
On Fri, Apr 16, 2010 at 10:42 AM, Heath Oderman wrote:
> Any pointers on why a thrift client would fly against cass on one os vs
> another? The only delta is os.
>
That's probably not the only delta. There's networking involved too, so
perhaps the problem lies there. Let us know how stress.py
Any pointers on why a thrift client would fly against cass on one os vs
another? The only delta is os.
I'm going to try py_stress remote.
Stu
On Apr 16, 2010 11:39 AM, "Jonathan Ellis" wrote:
Sounds like the problem is with the C# client code, then.
On Fri, Apr 16, 2010 at 10:36 AM, Heath O
Sounds like the problem is with the C# client code, then.
On Fri, Apr 16, 2010 at 10:36 AM, Heath Oderman wrote:
> Ok, it took me a long time to get py_stress working.
> I didn't have thrift / boost / gcc on my debian box :)
> I'm using this command line believing it's similar to my c# test
Ok, it took me a long time to get py_stress working.
I didn't have thrift / boost / gcc on my debian box :)
I'm using this command line believing it's similar to my c# tests from a
remote box:
cnb:~/apache-cassandra-0.6.0-src/contrib/py_stress# python stress.py -o
insert -n 100 -d 10.1
I upgraded to 0.6 yesterday and it's bang on the same. I'll go read up on
py_stress and give it a try.
On Thu, Apr 15, 2010 at 1:57 PM, Jonathan Ellis wrote:
> What kind of numbers do you get from contrib/py_stress?
>
> (that's located somewhere else in 0.5, but you should really be using
> 0.6
What kind of numbers do you get from contrib/py_stress?
(that's located somewhere else in 0.5, but you should really be using
0.6 anyway.)
On Thu, Apr 15, 2010 at 12:53 PM, Heath Oderman wrote:
> So checking it out quickly:
> vmstat -
> Never swaps. si and so stay at 0 during the load.
> iosta
So checking it out quickly:
vmstat -
Never swaps. si and so stay at 0 during the load.
iostat -x
the %util never climbs above 0.00, but the avgrg-sz jumps bewteen samples
from 0 - 30 - 90 - 0 (5 second intervals)
top shows the cpu barely working and mem utilization is below 20%.
Still slow.
Thanks Jonathan, I'll check this out right away.
On Thu, Apr 15, 2010 at 1:32 PM, Jonathan Ellis wrote:
> You're right, to get those numbers on debian something is very wrong.
>
> Have you looked at
> http://spyced.blogspot.com/2010/01/linux-performance-basics.html ?
> What is the bottleneck on
You're right, to get those numbers on debian something is very wrong.
Have you looked at
http://spyced.blogspot.com/2010/01/linux-performance-basics.html ?
What is the bottleneck on the linux machines?
With the kind of speed you are seeing I wouldn't be surprised if it is swapping.
-Jonathan
On
Hi,
sorry I can't help you, but could you please tell me, how could you get the
charts in the attachment?
Thanks.
Mike
On Wed, Apr 14, 2010 at 6:38 AM, Heath Oderman wrote:
> Hi,
>
> I wrote a few days ago and got a few good suggestions. I'm still seeing
> dramatic differences between Cassand
20 matches
Mail list logo
