we are using functional tests ( ~500 tests in time). it is hard to tell which query is slower, it is "slower in general".
same hardware. 1 node, 32Gb RAM, 8Gb heap. default cassandra settings. as we are talking about functional tests, so we recreate KS just before tests are run. I do not know how to record queries (there are a lot of them), if you are interested, I can set up a special stand for you. 2012/8/31 aaron morton <aa...@thelastpickle.com> > we are running somewhat queue-like with aggressive write-read patterns. > > We'll need some more details... > > How much data ? > How many machines ? > What is the machine spec ? > How many clients ? > Is there an example of a slow request ? > How are you measuring that it's slow ? > Is there anything unusual in the log ? > > Cheers > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 31/08/2012, at 3:30 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > > If you move from 7.X to 0.8X or 1.0X you have to rebuild sstables as > soon as possible. If you have large bloomfilters you can hit a bug > where the bloom filters will not work properly. > > > On Thu, Aug 30, 2012 at 9:44 AM, Илья Шипицин <chipits...@gmail.com> > wrote: > > we are running somewhat queue-like with aggressive write-read patterns. > I was looking for scripting queries from live Cassandra installation, but I > didn't find any. > > is there something like thrift-proxy or other query logging/scripting > engine > ? > > 2012/8/30 aaron morton <aa...@thelastpickle.com> > > > in terms of our high-rate write load cassandra1.0.11 is about 3 (three!!) > times slower than cassandra-0.7.8 > > We've not had any reports of a performance drop off. All tests so far have > show improvements in both read and write performance. > > I agree, such digests save some network IO, but they seem to be very bad > in terms of CPU and disk IO. > > The sha1 is created so we can diagnose corruptions in the -Data component > of the SSTables. They are not used to save network IO. > It is calculated while streaming the Memtable to disk so has no impact on > disk IO. While not the fasted algorithm I would assume it's CPU overhead in > this case is minimal. > > there's already relatively small Bloom filter file, which can be used for > saving network traffic instead of sha1 digest. > > Bloom filters are used to test if a row key may exist in an SSTable. > > any explanation ? > > If you can provide some more information on your use case we may be able > to help. > > Cheers > > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 30/08/2012, at 5:18 AM, Илья Шипицин <chipits...@gmail.com> wrote: > > in terms of our high-rate write load cassandra1.0.11 is about 3 (three!!) > times slower than cassandra-0.7.8 > after some investigation carried out I noticed files with "sha1" extension > (which are missing for Cassandra-0.7.8) > > in maybeWriteDigest() function I see no option fot switching sha1 digests > off. > > I agree, such digests save some network IO, but they seem to be very bad > in terms of CPU and disk IO. > why to use one more digest (which have to be calculated), there's already > relatively small Bloom filter file, which can be used for saving network > traffic instead of sha1 digest. > > any explanation ? > > Ilya Shipitsin > > > > >
