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. Although the table is defined to use Snappy Compression. Is this compression library or some other transitive dependency pulled in by Astyanax enabling compression of the payload i.e. sent over the wire and account for the difference in tp99? Regards Sachin
On Mon, Aug 3, 2015 at 12:14 AM, Janne Jalkanen <janne.jalka...@ecyrd.com> wrote: > > 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 > production environments, if you choose not to enable compression now. > > /Janne > > On 3 Aug 2015, at 08:40, Sachin Nikam <skni...@gmail.com> wrote: > > 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 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 >> >> Client <- [uncompressed data] -> Server <- [compressed data] -> Disk. >> >> To fix, make sure that the Snappy libraries are in the classpath of your >> S3 service application. As always, there’s no guarantee that this improves >> your performance, since if your app is already CPU-heavy, the extra CPU >> overhead of compression *may* be a problem. So measure :-) >> >> /Janne >> >> On 02 Aug 2015, at 02:17 , Sachin Nikam <skni...@gmail.com> wrote: >> >> I am currently running a Cassandra 1.2 cluster. This cluster has 2 tables >> i.e. >> TableA and TableB. >> >> TableA is read and written to by Services S1 and S2 which use Astyanax >> client library. >> >> TableB is read and written by Service S3 which uses the datastax java >> driver 2.1. S3 also reads data from TableA. >> >> Both TableA and TableB are defined on the Cassandra nodes to use >> SnappyCompressor. >> >> On start-up service, Service S3 throws the following WARNing messages. >> The service is able to continue doing its normal operation thereafter >> >> ************** >> [main] WARN loggerClass=com.datastax.driver.core.FrameCompressor;Cannot >> find Snappy class, you should make sure the Snappy library is in the >> classpath if you intend to use it. Snappy compression will not be >> available for the protocol. >> *********** >> >> >> My questions are as follows-- >> #1. Does the compression happen on the cassandra client side or within >> cassandra server side itself? >> #2. Does Service S3 need to pull in additional dependencies for Snappy >> Compressions as mentioned here -- >> >> http://stackoverflow.com/questions/21784149/getting-cassandra-connection-error >> #3. What happens without this additional library not being present on >> class path of Service S3. Any data that S3 writes to TableB will not be >> compressed? >> Regards >> Sachin >> >> >> > >
