incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher McKenzie" <>
Subject RE: Performance of get
Date Tue, 27 Oct 2009 20:00:24 GMT
First, my email client died, so I don't know if my original response went out.  I apologize
if there is a duplicate here:

Thanks for the info on get_slice -- it's serving me well now. However, your response definitely
rubbed me the wrong way.

Exceptions are a special feature of languages often with their own keywords, primitives, and
usually chapters in books.  I don't profess to be an expert in the various exception models
for all the versions of various implementations of C++, Java, Python, PHP, Ruby, Erlang, Perl,
Haskell, C#, Cocoa, Smalltalk, and OCaml that thrift supports.  But I would claim that, with
such a large heterogeneous and dynamic support base, one should use something as varied and
unpredictable as the exception handling models with great care and I don't "personally feel"
that the understandably expected error case of Get should be escalated to be handled by this

I'm curious as to what others think about this - I realize that handling this case is more
philosophy driven then anything.  Thanks...

-----Original Message-----
From: Jonathan Ellis []
Sent: Tue 10/27/2009 11:35 AM
Subject: Re: Performance of get
On Tue, Oct 27, 2009 at 12:20 PM, Christopher McKenzie
<> wrote:
> Checking for existence, a normal control flow operation, requires using a
> try/catch method, which are not intended for normal control flow.

That was conventional wisdom in the '80s.  Less so today.  (Along with
gems like "there should only be one return point from any function."
Remember that one?)

> My experience with PHP has shown that interrupts come at a cost of about 200
> times that of a type check.
> Could Get possibly return a reserved value instead?

Sorry, it's not worth breaking everyone's existing code to accommodate
the PHP vm sucking.

Have you actually tested to make sure it's not fast "enough?"  I'm
really skeptical that even with a terrible exception design, this will
be the bottleneck compared with network + cassandra latency + the rest
of your code.

If it really is your bottleneck, you have a couple options:
 - use get_slice, which will return an empty list instead of throwing
NFE [the thrift interface declares that it throws, but this is wrong,
I will fix it]
 - use python; we just did some testing with a miss-dominated workload
and the client was not a bottleneck even at 20000+ req/s


View raw message