incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <>
Subject Re: Performance degradation observed through embedded cassandra server - pointers needed
Date Thu, 22 Sep 2011 14:01:19 GMT
On Thu, Sep 22, 2011 at 9:27 AM, Roshan Dawrani <>wrote:

> Hi,
> We recently switched from Cassandra 0.7.2 to 0.8.5 and observing
> considerable performance degradation in embedded server's response times
> that we use in integration tests.
> One thing that we do is that we truncate our app column families after each
> integration test so that the next one gets a new DB slate (wierd? but with
> RDBMS that we used earlier, we just rolled back the transaction to get rid
> of changes done in an integration test. CF truncation is a costly workaround
> for that, which we will be very happy to avoid if anyone knows some trick).
> So, with the situation we are in, is anyone aware of any cassandra 0.8.5
> cofiguration that can be tweaked to at least get the performance we were
> getting with 0.7.2? Exactly after the upgrade, our test execution times have
> gone up at least by 60-70%.
> Some pointers please?
> Thanks.
> --
> Roshan
> Blog:
> Twitter: @roshandawrani <>
> Skype: roshandawrani
1) Should should try to dig in an determine why the truncate is slower. Look
for related jira issues on truncation.

Cassandra had some re-entrant code you could fork a JVM each test and use
the CassandraServiceDataCleaner. (However multiple startups could end up
causing more overhead then the truncation)

I avoid this problem by using a different column family and or a different
keyspaces for all my unit tests in a single class. Each class bring up a new
embedded cluster and uses the data cleaner to sanitize the data directories.
So essentially I never call truncate.

View raw message