[
https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17207306#comment-17207306
]
Michael Semb Wever commented on CASSANDRA-16079:
------------------------------------------------
bq. Is it necessary to stop the cluster to cache it and then start it again?
Can't we just flush and copy the directory without stopping the cluster? This
might shave some restart time.
It might shave some time. But I think the benefits, based on what re-use
there'll be within splits, will be touch-n-go without a centralised cache
approach. The copy of a file tree isn't atomic either, so I would presume we'd
be opening for edge-case bugs here. No one wants more flakey dtests :(
Note, in that approach the subsequent ccm start was all nodes in parallel
(which is much faster ofc).
bq. Couldn't we keep use random allocation by default on dtests to be able to
bootstrap in parallel, and have a new suite of dtests executed nightly and
before release (similar to novnode) with the new token allocation enabled?
A number of folk have raised this. I believe the general preference is that we
want the dtests to test the default config settings, especially to help
identify flaky dtests during 4.0-beta.
> Improve dtest runtime
> ---------------------
>
> Key: CASSANDRA-16079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16079
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
> Reporter: Adam Holmberg
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 4.0-beta, 4.0-triage
>
> Attachments: Screenshot 2020-09-19 at 12.32.21.png
>
>
> A recent ticket, CASSANDRA-13701, changed the way dtests run, resulting in a
> [30% increase in run
> time|https://www.mail-archive.com/[email protected]/msg15606.html].
> While that change was accepted, we wanted to spin out a ticket to optimize
> dtests in an attempt to gain back some of that runtime.
> At this time we don't have concrete improvements in mind, so the first order
> of this ticket will be to analyze the state of things currently, and try to
> ascertain some valuable optimizations. Once the problems are understood, we
> will break down subtasks to divide the work.
> Some areas to consider:
> * cluster reuse
> * C* startup optimizations
> * Tests that should be ported to in-JVM dtest or even unit tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
