-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-17472: Speed Up DescribeConsumerGroupTest #17117
Conversation
If add the
|
639a6bc
to
50464cd
Compare
If add the max.poll.interval.ms to 1000 and
|
@m1a2st could you please merge trunk to run CI again? |
d9aca00
to
17bf18d
Compare
This |
@@ -987,6 +987,7 @@ private Map<String, Object> composeConfigs(String groupId, String groupProtocol, | |||
configs.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName()); | |||
configs.put(ConsumerConfig.GROUP_PROTOCOL_CONFIG, groupProtocol); | |||
configs.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, RangeAssignor.class.getName()); | |||
configs.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, "1000"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pardon me, not sure why we need to add this config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it seems to me group.consumer.heartbeat.interval.ms
is the true critical config, as they needs some HB cycles to reach the stable group.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pardon me, not sure why we need to add this config
The document write that
A new config, group.initial.rebalance.delay.ms, was introduced. This config specifies the time, in milliseconds, that the GroupCoordinator will delay the initial consumer rebalance. The rebalance will be further delayed by the value of group.initial.rebalance.delay.ms as new members join the group, up to a maximum of max.poll.interval.ms. The default value for this is 3 seconds. During development and testing it might be desirable to set this to 0 in order to not delay test execution time.
This config will work in test, thus I think that it is useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The config I didn't catch is group.initial.rebalance.delay.ms
rather than max.poll.interval.ms
. max.poll.interval.ms
the the upper limit of "timeout" and in testing we don't expect to see timeout, so I can't understand the purpose of reducing the value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, the test should not expect timeout, I misunderstanding the max.poll.interval.ms
config
|
@@ -85,6 +88,9 @@ static List<ClusterConfig> forKRaftGroupCoordinator() { | |||
Map<String, String> serverProperties = new HashMap<>(); | |||
serverProperties.put(OFFSETS_TOPIC_PARTITIONS_CONFIG, "1"); | |||
serverProperties.put(OFFSETS_TOPIC_REPLICATION_FACTOR_CONFIG, "1"); | |||
serverProperties.put(GROUP_INITIAL_REBALANCE_DELAY_MS_CONFIG, "1000"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @m1a2st, one question, based on the document of group.initial.rebalance.delay.ms
. (Link)
The default value for this is 3 seconds. During development and testing it might be desirable to set this to 0 in order to not delay test execution time.
I think setting group.initial.rebalance.delay.ms
to zero might be better. Is there have any reason we use 1000 ms?
I can see some tests are using 1000ms, but some others are using 0ms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @chenyulin0719, You can see this discussion, we set the group.initial.rebalance.delay.ms
from 3000 to 1000 to not only keep the initial rebalance delay but also speed up the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Comparing to set group.initial.rebalance.delay.ms
to 0 ms, adding some delay could speed up the metadata synchronization in Kraft mode. Let's a suprising finding to me.
Thanks for sharing the discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think setting group.initial.rebalance.delay.ms to zero might be better.
That is good, but we want to have delay in testing. That can "reduce" the difference between test and production. Also, 1.5s is good enough in speedup.
@m1a2st please don't use "force push" again. My previous comment about using |
sorry that please ignore this comment. I looked at incorrect PR 😢 |
Reviewers: Chia-Ping Tsai <[email protected]>
Jira: https://issues.apache.org/jira/browse/KAFKA-17472
The DescribeConsumerGroupTest is slow, we should add some config to speed up this test
Committer Checklist (excluded from commit message)