cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6553) Benchmark counter improvements (counters++)
Date Sat, 15 Mar 2014 09:40:43 GMT


Sylvain Lebresne commented on CASSANDRA-6553:

bq. there are some other scenarios to test - when the read before write hits the disk, for

That's actually largely what I meant by testing with the counter cache disabled. The new counter
implem has a (new) counter cache that saves the read-before-write from hitting disk on a cache
hit. So a simple way to check what happen when you run out of cache would be to just disable
it, which can be done from the yaml (check the counter_cache_* new options).

> Benchmark counter improvements (counters++)
> -------------------------------------------
>                 Key: CASSANDRA-6553
>                 URL:
>             Project: Cassandra
>          Issue Type: Test
>            Reporter: Ryan McGuire
>            Assignee: Russ Hatch
>             Fix For: 2.1 beta2
>         Attachments:, 6553.uber.quorum.bdplab.write.png,
high_cl_one.png, high_cl_quorum.png, low_cl_one.png, low_cl_quorum.png, tracing.txt, uber_cl_one.png,
> Benchmark the difference in performance between CASSANDRA-6504 and trunk.
> * Updating totally unrelated counters (different partitions)
> * Updating the same counters a lot (same cells in the same partition)
> * Different cells in the same few partitions (hot counter partition)
> benchmark:
(old counters)
> compared to:
(new counters)
> So far, the above changes should only affect the write path.

This message was sent by Atlassian JIRA

View raw message