tlp-stress has support for customizing payloads, but it's not
documented very well. For a given data model (say the KeyValue one),
you can override what tlp-stress will send over. By default it's
pretty small, a handful of bytes.
If you pass --field.keyvalue.value (the table name + the field nam
tlp-stress allow us to define size of rows? Because I will see the benefit
of compression in terms of request rates only if the compression ratio is
significant, i.e. requires less network round trips.
This could be done generating bigger partitions with parameters -n and -p,
i.e. decreasing the -p
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 compress
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 prob
