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.em...@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.kes...@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 <arvydas.jonuso...@gmail.com> >> *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. >> >> >> >> http://www.datastax.com/dev/blog/java-driver-async-queries >> >> >> >> >> >> On Sat, Mar 18, 2017 at 08:00 S G <sg.online.em...@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.jonuso...@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(..) ? >> >> >> >> >> >
