Yes, I have an idea forming up in my mind for 5220, so I'm still on it. On Wed, Apr 16, 2014 at 6:25 AM, Benedict Elliott Smith <belliottsm...@datastax.com> wrote: >> >> - CASSANDRA-5220: Repair improvements when using vnodes > > > That definitely deserves a "performance" tag. Yuki, are you looking at this > or should we unassign in case somebody else wants to jump in? > > > On 15 April 2014 14:59, Michael Shuler <mich...@pbandjelly.org> wrote: > >> On 04/15/2014 08:28 AM, Benedict Elliott Smith wrote: >> >>> It's only been six months since the last performance drive, and 2.1 is now >>> around the corner. But I'm hoping we can push performance even further for >>> 3.0. With that in mind, I've picked out what I think are the nearest term >>> wins to focus on. >>> >>> - CASSANDRA-7039: DirectByteBuffer compatible LZ4 methods >>> - CASSANDRA-6726: RAR/CRAR off-heap >>> - CASSANDRA-6633: Dynamic bloom filter resizing >>> - CASSANDRA-6755: Optimise CellName/Composite comparisons for >>> NativeCell >>> - CASSANDRA-7032: Improve vnode allocation >>> - CASSANDRA-6809: Compressed Commit Log >>> - CASSANDRA-5663: write batching in native protocol >>> - CASSANDRA-5863: In-process (uncompressed) page cache >>> - CASSANDRA-7040: Replace read/write stage with per-disk access >>> coordination >>> - CASSANDRA-6917: enum data type >>> - CASSANDRA-6935: Make clustering part of primary key a first order >>> >>> component in the storage engine >>> >>> I've arranged them in ascending order of my intuitive impression of their >>> difficulty. Don't all leap at the last few :) >>> >>> Anything I've missed? >>> >> >> - CASSANDRA-5220: Repair improvements when using vnodes >> >> Not sure where that might go in your difficulty ordering, but since vnodes >> are default and repair time seems to be a pretty common question/pain, it's >> important for ops and highly relevant to cluster performance. If some of >> the above list might directly affect/help repair performance, let's get >> them tied together in Jira :) >> >> -- >> Kind regards, >> Michael >> >>
-- Yuki Morishita t:yukim (http://twitter.com/yukim)
