To summarize this thread, I think people are generally okay with updating certain defaults for 4.0 provided we make sure it doesn't unpleasantly surprise cluster operators. I think with the num_tokens and compaction_throughput_in_mb we could go with a release note for the reasons in my last email. I also agree that we should consider bump roles_validity_in_ms, permissions_validity_in_ms, and credentials_validity_in_ms along with the default snitch (going to GPFS as the default) as that gives people a DC aware default at least to start.
Is everyone okay if I create tickets for each of these and link them with an epic so that we can discuss them separately? Thanks, Jeremy On Thu, Jan 23, 2020 at 5:34 AM Alex Ott <alex...@gmail.com> wrote: > In addition to these, maybe we could consider to change other as well? > Like: > > 1. bump roles_validity_in_ms, permissions_validity_in_ms, and > credentials_validity_in_ms as well - maybe at least to a minute, or 2. I > have seen multiple times when authentication was failing under the heavy > load because queries to system tables were timing out - with these > defaults people may still have the possibility to get updates to > roles/credentials faster when specifying _update_interval_ variants of > these configurations. > 2. change default snitch from SimpleSnitch to GossipingPropertyFileSnitch - > we're anyway saying that SimpleSnitch is only appropriate for > single-datacenter deployments, and for real production we need to use > GossipingPropertyFileSnitch - why not to set it as default? > > > Jeremy Hanna at "Wed, 22 Jan 2020 11:22:36 +1100" wrote: > JH> I mentioned this in the contributor meeting as a topic to bring up on > the list - should we > JH> take the opportunity to update defaults for Cassandra 4.0? > > JH> The rationale is two-fold: > JH> 1) There are best practices and tribal knowledge around certain > properties where people > JH> just know to update those properties immediately as a starting > point. If it's pretty much > JH> a given that we set something as a starting point different than the > current defaults, why > JH> not make that the new default? > JH> 2) We should align the defaults with what we test with. There may be > exceptions if we > JH> have one-off tests but on the whole, we should be testing with > defaults. > > JH> As a starting point, compaction throughput and number of vnodes seem > like good candidates > JH> but it would be great to get feedback for any others. > > JH> For compaction throughput ( > https://jira.apache.org/jira/browse/CASSANDRA-14902), I've made > JH> a basic case on the ticket to default to 64 just as a starting point > because the decision > JH> for 16 was made when spinning disk was most common. Hence most > people I know change that > JH> and I think without too much bikeshedding, 64 is a reasonable > starting point. A case > JH> could be made that empirically the compaction throughput throttle may > have less effect > JH> than many people think, but I still think an updated default would > make sense. > > JH> For number of vnodes, Michael Shuler made the point in the discussion > that we already test > JH> with 32, which is a far better number than the 256 default. I know > many new users that > JH> just leave the 256 default and then discover later that it's better > to go lower. I think > JH> 32 is a good balance. One could go lower with the new algorithm but > I think 32 is much > JH> better than 256 without being too skewed, and it's what we currently > test. > > JH> Jeff brought up a good point that we want to be careful with defaults > since changing them > JH> could come as an unpleasant surprise to people who don't explicitly > set them. As a > JH> general rule, we should always update release notes to clearly state > that a default has > JH> changed. For these two defaults in particular, I think it's safe. > For compaction > JH> throughput I think a release not is sufficient in case they want to > modify it. For number > JH> of vnodes, it won't affect existing deployments with data - it would > be for new clusters, > JH> which would honestly benefit from this anyway. > > JH> The other point is whether it's too late to go into 4.0. For these > two changes, I think > JH> significant testing can still be done with these new defaults before > release and I think > JH> testing more explicitly with 32 vnodes in particular will give people > more confidence in > JH> the lower number with a wider array of testing (where we don't > already use 32 explicitly). > > JH> In summary, are people okay with considering updating these defaults > and possibly others > JH> in the alpha stage of a new major release? Are there other > properties to consider? > > JH> Jeremy > JH> --------------------------------------------------------------------- > JH> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > JH> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > With best wishes, Alex Ott > Principal Architect, DataStax > http://datastax.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
