Hi Jeff, Thank you very much for your response. Your considerations are definitely right but, at this point, I just want to consider the Cassandra response time on different Azure VMs size.
Yes, the YCSB GC can impact on it but the total time that YCSB spent with the GC is ~ 3% of the total experiment time (results provided by the end of YCSB execution). In the results I got, the YCSB is more than 4 times higher than the one gathered from each node. Thanks Salvatore 2018-03-05 14:59 GMT+00:00 Jeff Jirsa <jji...@gmail.com>: > > > > On Mar 5, 2018, at 6:52 AM, D. Salvatore <dd.salvat...@gmail.com> wrote: > > Hello everyone, > I am benchmarking a Cassandra installation on Azure composed of 4 nodes > (Standard_D2S_V3 - 2vCPU and 8GB ram) with a replication factor of 2. > > > Bit smaller than most people would want to run in production. > > To benchmark this testbed, I am using a single YCSB instance with the > workload C (100% read request), a Consistency level ONE and only 10 clients > ( so very low load). > > > Be sure that you understand the difference between your benchmark and your > prod use case - especially differences in data model and consistency levels. > > > However, I founded that the average latency gathered by YCSB is much > different from the one obtained from the JMX (org.apache.cassandra.metrics: > type=ClientRequest,scope=Read,name=Latency) > I ran the workload for over an hour and: > - YCSB returns around 4000 us as average latency > - JMX returns around 780 us as average latency > > It is a quite an important difference in performance that I don't know how > to justify. > Do you have any idea from where this difference comes from? > > > Could be app side pauses (ycsb being java itself, could be seeing jvm gc > on the load testing servers) > > > Regarding the throughput, the value is the same across both the reading > (~2400ops/sec) > > Thank in advance > Salvatore > >
