Which setting controls how much data you want to pull at least on each request?

Which setting controls how much data you want to pull at least on each request?

• A. max.poll.records
• B. fetch.min.bytes
• C. max.partition.fetch.bytes
• D. fetch.max.bytes

Answer: (B)

The setting being tested controls how much data the broker should return in a fetch response at a minimum. It tells the broker to wait until it has gathered at least a certain number of bytes before replying to a fetch, so you can ensure you pull a sizable chunk rather than tiny, frequent replies. If there isn’t enough data yet, the broker will hold off until either that minimum is reached or a timeout occurs (governed by another fetch timeout setting). This lets you trade latency for throughput: raise the minimum to get larger, fewer fetches, or lower it to get quicker responses. By contrast, other options cap how much data can be returned in a single fetch, or limit data per partition, or limit how many records are returned per poll—these affect bounds or counts rather than the minimum amount fetched per request.

The setting being tested controls how much data the broker should return in a fetch response at a minimum. It tells the broker to wait until it has gathered at least a certain number of bytes before replying to a fetch, so you can ensure you pull a sizable chunk rather than tiny, frequent replies. If there isn’t enough data yet, the broker will hold off until either that minimum is reached or a timeout occurs (governed by another fetch timeout setting). This lets you trade latency for throughput: raise the minimum to get larger, fewer fetches, or lower it to get quicker responses. By contrast, other options cap how much data can be returned in a single fetch, or limit data per partition, or limit how many records are returned per poll—these affect bounds or counts rather than the minimum amount fetched per request.