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, <email@example.com> 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
..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 <firstname.lastname@example.org> 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 <email@example.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(..) ?