If it were me, I'd look at raw request rates (in terms of requests / second as well as request latency), network throughput and then some flame graphs of both the server and your application: https://github.com/jvm-profiling-tools/async-profiler.
I've created an issue in tlp-stress to add compression options for the driver: https://github.com/thelastpickle/tlp-stress/issues/67. If you're interested in contributing the feature I think tlp-stress will more or less solve the remainder of the problem for you (the load part, not the os numbers). Jon On Mon, Apr 8, 2019 at 7:26 AM Gabriel Giussi <gabrielgiu...@gmail.com> wrote: > > Hi, I'm trying to test if adding driver compression will bring me any benefit. > I understand that the trade-off is less bandwidth but increased CPU usage in > both cassandra nodes (compression) and client nodes (decompression) but I > want to know what are the key metrics and how to monitor them to probe > compression is giving good results? > I guess I should look at latency percentiles reported by > com.datastax.driver.core.Metrics and CPU usage, but what about bandwith usage > and compression ratio? > Should I use tcpdump to capture packets length coming from cassandra nodes? > Something like tcpdump -n "src port 9042 and tcp[13] & 8 != 0" | sed -n > "s/^.*length \(.*\).*$/\1/p" would be enough? > > Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
