Yes. please do. We should also update our JVM defaults. On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote:
> 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 > > > > >
