Performance Tickets
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?
Re: Performance Tickets
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
Re: Performance Tickets
And here's the Grand List of all performance tickets: https://issues.apache.org/jira/issues/?jql=labels%20%3D%20performance%20and%20project%20%3D%20CASSANDRA%20AND%20status!%3Dresolved Benedict, you might want to un-assign from yourself anything you're not working on in the near future in case anyone else wants to grab one. On Tue, Apr 15, 2014 at 3:28 PM, 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? -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Performance Tickets
I thought I'd spammed the change list enough for one day, but since you mention it... :-) On 15 April 2014 23:40, Jonathan Ellis wrote: > And here's the Grand List of all performance tickets: > > https://issues.apache.org/jira/issues/?jql=labels%20%3D%20performance%20and%20project%20%3D%20CASSANDRA%20AND%20status!%3Dresolved > > Benedict, you might want to un-assign from yourself anything you're > not working on in the near future in case anyone else wants to grab > one. > > On Tue, Apr 15, 2014 at 3:28 PM, 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? > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >
