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
