Re: CASSANDRA-13241 lower default chunk_length_in_kb
Shall we move this discussion to a separate thread? I agree it needs to be had, but this will definitely derail this discussion.
To respond only to the relevant portion for this thread:
> changing years-old defaults
I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature we’re changing - most users don’t even know to change this parameter, so we can’t claim its length of existence works in its favour.
The project had fewer resources to be as thorough when this tickets landed, so we can’t even claim we’re overturning careful work. This default was defined in 2011 with no performance comparisons with other possible sizes, or justification for the selection made on ticket (CASSANDRA-47 - yes, they once went down to two digits!).
That’s not to say this wasn’t a fine default - it was. In this case, age has actively worked against it. Since 2011, SSDs have become the norm, and most servers have more memory than we are presently able to utilise effectively.
This is a no brainer, and doesn’t have any impact on testing. Tests run with 64KiB are just as valid as those run with 16KiB. Performance tests should anyway compare like-to-like, so this is completely testing neutral AFAICT.
> On 19 Oct 2018, at 15:16, Joshua McKenzie <jmckenzie@xxxxxxxxxx> wrote:
> At the risk of hijacking this thread, when are we going to transition from
> "no new features, change whatever else you want including refactoring and
> changing years-old defaults" to "ok, we think we have something that's
> stable, time to start testing"?
> Right now, if the community starts aggressively testing 4.0 with all the
> changes still in flight, there's likely going to be a lot of wasted effort.
> I think the root of the disconnect was that when we discussed "freeze" on
> the mailing list, it was in the context of getting everyone engaged in
> testing 4.0.