[
https://issues.apache.org/jira/browse/CASSANDRA-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199625#comment-17199625
]
Ekaterina Dimitrova edited comment on CASSANDRA-16079 at 9/21/20, 7:43 PM:
---------------------------------------------------------------------------
I second what Berenguer said here. Also, I think the reusage of classes/methods
is a bit more tricky. The way I was thinking of it and experimented over the
weekend a bit was - reusable cluster but if cleaning is not done properly this
is more error-prone solution. Also, it will be of benefit only for Circle at
the moment and Circle (circle splits are on time&class level as per the config
file now if I read this correctly ---split-by=timings --timings-type=classname)
is not the main project CI.
Also, caching of bootstrapped ccm should be of use for both Circle and Jenkins.
If there is a need probably we can do additional splits/grouping of tests to
help Circle more which shouldn't be hard(right?).
A thing we can explore in this case too is the caching layer in circle whether
we can use it now, maybe? Not sure also credit-wise whether this will be of
benefit but we can explore it.
was (Author: e.dimitrova):
I second what Berenguer said here. Also, I think the reusage of classes/methods
is a bit more tricky. The way I was thinking of it and experimented over the
weekend a bit was - reusable cluster but if cleaning is not done properly this
is more error-prone solution. Also, it will be of benefit only for Circle at
the moment and Circle (circle splits as per the config file now if I read this
correctly ---split-by=timings --timings-type=classname) is not the main project
CI.
Also, caching of bootstrapped ccm should be of use for both Circle and Jenkins.
If there is a need probably we can do additional splits/grouping of tests to
help Circle more which shouldn't be hard(right?).
A thing we can explore in this case too is the caching layer in circle whether
we can use it now, maybe? Not sure also credit-wise whether this will be of
benefit but we can explore it.
> 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
> Priority: Normal
> Fix For: 4.0-beta
>
> 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/dev@cassandra.apache.org/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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
