Forgot to mention that this vmstat picture is for the client-cluster reading from Cassandra.

On Sat, Mar 18, 2017 at 6:47 PM, S G <sg.online.email@gmail.com> wrote:
ok, I gave the executeAsync() a try.
Good part is that it was really easy to write the code for that.
Bad part is that it did not had a huge effect on my throughput - I gained about 5% increase in throughput.
I suspect it is so because my queries are all get-by-primary-key queries and were anyways completing in less than 2 milliseconds.
So there was not much wait to begin with.


Here is my code:

String getByKeyQueryStr = "Select * from fooTable where key = " + key;
//ResultSet result = session.execute(getByKeyQueryStr);  // Previous code
ResultSetFuture future = session.executeAsync(getByKeyQueryStr);
FutureCallback<ResultSet> callback = new MyFutureCallback();
executor = MoreExecutors.sameThreadExecutor();
//executor = Executors.newFixedThreadPool(3); // Tried this too, no effect
//executor = Executors.newFixedThreadPool(10); // Tried this too, no effect
Futures.addCallback(future, callback, executor);

Can I improve the above code in some way?
Are there any JMX metrics that can tell me what's going on?

From the vmstat command, I see that CPU idle time is about 70% even though I am running about 60 threads per VM
Total 20 client-VMs with 8 cores each are querying a Cassandra cluster with 16 VMs, 8-core each too.






Thanks
SG


On Sat, Mar 18, 2017 at 5:38 PM, S G <sg.online.email@gmail.com> wrote:
Thanks. It seems that you guys have found executeAsync to yield good results.
I want to share my understanding how this could benefit performance and some validation from the group will be awesome.

I will call executeAsync() each time I want to get by primary-key.
That ways, my client thread is not blocked anymore and I can submit a lot more requests per unit time.
The async requests get piled on the underlying Netty I/O thread which ensures that it is always busy all the time.
Earlier, the Netty I/O thread would have wasted some cycles when the sync-execute method was processing the results.
And earlier, the client thread would also have wasted some cycles waiting for netty-thread to complete.

With executeAsync(), none of them is waiting.
Only thing to ensure is that the Netty thread's queue does not grow indefinitely.

If the above theory is correct, then it sounds like a really good thing to try.
If not, please do share some more details.




On Sat, Mar 18, 2017 at 2:00 PM, <j.kesten@enercast.de> wrote:

+1 for executeAsync – had a long time to argue that it’s not bad as with good old rdbms.

 

 

 

Gesendet von meinem Windows 10 Phone

 

Von: Arvydas Jonusonis
Gesendet: Samstag, 18. März 2017 19:08
An: user@cassandra.apache.org
Betreff: Re: How can I scale my read rate?

 

..then you're not taking advantage of request pipelining. Use executeAsync - this will increase your throughput for sure.

 

 

 

On Sat, Mar 18, 2017 at 08:00 S G <sg.online.email@gmail.com> wrote:

I have enabled JMX but not sure what metrics to look for - they are way too many of them.

I am using session.execute(...)

 

 

On Fri, Mar 17, 2017 at 2:07 PM, Arvydas Jonusonis <arvydas.jonusonis@gmail.com> wrote:

It would be interesting to see some of the driver metrics (in your stress test tool) - if you enable JMX, they should be exposed by default.

Also, are you using session.execute(..) or session.executeAsync(..) ?