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 probably has some impact on end-to-end latency, but there are multiple other things which also impact latency, such as whether you’re using prepared queries with the Datastax driver, how large your queries are, etc. In general the consensus seems to be that using CQL over the Datastax driver is 1) very fast and since 2.1 of Cassandra, arguably faster than the Thrift interface that the older clients still use, b) the clarity of the CQL interface gives a productivity boost for developers and iii) all new features will be implemented using it, so using CQL is future-proof. /Janne > On 5 Aug 2015, at 06:34, Sachin Nikam <skni...@gmail.com> wrote: > > 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 > <mailto:skni...@gmail.com>> wrote: > 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 > <mailto: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 >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>> >>> <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 >> >> > > >
