cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacek Furmankiewicz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7088) Massive performance degradation for TRUNCATE when migrating to 2.0
Date Fri, 25 Apr 2014 14:50:14 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981074#comment-13981074
] 

Jacek Furmankiewicz commented on CASSANDRA-7088:
------------------------------------------------

Hm, so it's not so simple.

Basically we run regular BDD tests against the app (many REST calls back and forth) that result
in many read/writes from Cassandra in the back.
Between every test we truncate the DB to start clean for the next integration test.

So I would basically need to give you the whole app, which is rather impossible.

If there is anything we could trace through on our end I would be more than happy to do it.

a) Is there anything you could think of that changed between 1.2 and 2.0 that could cause
CF truncation to be much slower? (is auto_snapshot: false still respected?)

b) any idea what could cause the Zero length BigInteger exception?

Thank you

> Massive performance degradation for TRUNCATE when migrating to 2.0
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-7088
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7088
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Linux Mint 16
>            Reporter: Jacek Furmankiewicz
>         Attachments: cassandra.yaml
>
>
> We attempted to migrate our developers to Cassandra 2.0.7 from 1.2.
> Everything worked perfectly, but we have experienced a massive drop in developer velocity.
> We run integration tests with Cucumber BDD and 1000 BDDs went from 7 minutes (Cassandra
1.2) to 15 minutes (2.0.7),
> This is when we run Cassandra of the ramdisk (/dev/shm) to make it run faster on dev
boxes.
> When we tried pointed to actual drives  the difference was dramatic: the entire suite
took over 70 minutes (!) vs 15 in Cassandra 1.2.
> After investigation, we found that most of the time is spent in the truncation logic
between every scenario, where we truncate all the column families and start with a clean DB
for the next test case.
> This used to be super fast in 1.2, is now very slow in 2.0.
> It may not seem important, but upgrading to 2.0 has basically cut down developer velocity
by 100%, just by more than doubling the time it takes to run our BDD suite.
> We truncate the CFs using the Ruby driver:
>   $cassandra.column_families.each do |column_family|
>         name = column_family[0].to_s
>         $cassandra.truncate! name
>   end
> I am attaching our cassandra.yaml. Please note we already switched off auto_compaction
before truncate, just as we did in 1.2 for dev boxes, Made no difference.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message