[GitHub] [kafka] hachikuji commented on a diff in pull request #12153: MINOR: Clarify impact of num.replica.fetchers

[GitBox <gi...@apache.org>]

hachikuji commented on code in PR #12153:
URL: https://github.com/apache/kafka/pull/12153#discussion_r871786929


##########
core/src/main/scala/kafka/server/KafkaConfig.scala:
##########
@@ -894,7 +894,7 @@ object KafkaConfig {
     "record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker config) or " +
     "<code>max.message.bytes</code> (topic config)."
   val NumReplicaFetchersDoc = "Number of fetcher threads used to replicate messages from a source broker. " +
-  "Increasing this value can increase the degree of I/O parallelism in the follower broker."
+  "Increasing this value can increase the degree of I/O parallelism in the follower and leader broker at the cost of higher CPU utilization."

Review Comment:
   I agree for many users the additional explanation is unnecessary, but there is a vast range of expertise among all operators. I don't think there's any harm emphasizing the fact that there is a tradeoff here. I've seen some users increase this to 16 or higher and then act surprised when CPU usage becomes a problem.



##########
core/src/main/scala/kafka/server/KafkaConfig.scala:
##########
@@ -894,7 +894,7 @@ object KafkaConfig {
     "record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker config) or " +
     "<code>max.message.bytes</code> (topic config)."
   val NumReplicaFetchersDoc = "Number of fetcher threads used to replicate messages from a source broker. " +

Review Comment:
   I think the one thing this description should emphasize is that the value represents the number of fetchers for each broker that we are fetching from. This is implied by the phrase "from a source broker," but I can we can make it more explicit. How about this?
   
   > Number of fetcher threads used to replicate records from each source broker. The total number of fetchers on each broker is bound by `num.replica.fetchers` multiplied by the number of brokers in the cluster. Increasing this value can increase the degree of I/O parallelism in the follower and leader broker at the cost of higher CPU/memory utilization.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org