I’ve never used Astyanax, so it’s difficult to say, but if you can find the
snappy-java in the classpath, it’s quite possible that compression is enabled
for S1 and S2 automatically. You could try removing the snappy jar from S1 and
see if that changes the latencies compared to S2. ;-)
It
Janne,
A little clarification i found snappy-java-1.0.4.1.jar on class path. But
other questions still remain.
On Tue, Aug 4, 2015 at 8:24 PM, Sachin Nikam skni...@gmail.com wrote:
Janne,
Thanks for continuing to take the time to answer my queries. We noticed
that write latency (tp99) from
Janne,
Thanks for continuing to take the time to answer my queries. We noticed
that write latency (tp99) from Services S1 and S2 is 50% of the write
latency (tp99) for Service S3. I also noticed that S1 and S2, which also
use astyanax client library also have compress-lzf.jar on their class path.
Correct. Note that you may lose some performance this way though; in a typical
case saving bandwidth by increasing CPU usage is good. However, it always
depends on your usecase and whether you’re running your cluster to the max.
It’s a good, low-hanging optimization to keep in mind though for
No, this just tells that your client (S3 using Datastax driver) cannot
communicate to the Cassandra cluster using a compressed protocol, since the
necessary libraries are missing on the client side. Servers will still
compress the data they receive when they write it to disk.
In other words
Thanks Janne...
To clarify, Service S3 should not run in to any issues and I may choose to
not fix the issue?
Regards
Sachin
On Sat, Aug 1, 2015 at 11:50 PM, Janne Jalkanen janne.jalka...@ecyrd.com
wrote:
No, this just tells that your client (S3 using Datastax driver) cannot
communicate to the
