[jira] [Created] (KAFKA-8979) Fetch response is frequently split into multiple TCP/IP packets

["Piotr Smolinski (Jira)" <ji...@apache.org>]

Piotr Smolinski created KAFKA-8979:
--------------------------------------

             Summary: Fetch response is frequently split into multiple TCP/IP packets
                 Key: KAFKA-8979
                 URL: https://issues.apache.org/jira/browse/KAFKA-8979
             Project: Kafka
          Issue Type: Bug
          Components: core
    Affects Versions: 2.2.1
            Reporter: Piotr Smolinski
         Attachments: Screenshot 2019-10-04 at 13.58.48.png, dump.kafka.consumer.1.pcap

Checking the network dumps from Kafka I have observed that some Fetch response frames are split into multiple TCP segments. It adds some network overhead and forces additional TCP coordination. While it might make sense for zero-copy IO, the observed cases do not confirm this.

In the attached screenshot the 186 octets of Fetch response frame containing messages from 4 partitions (no actual messages were included in this case) are split into 7 TCP segments of length 8, 14, 12, 38, 38, 38 and 38 octets respectively.

In the observed cases, the frames are typically split into 8 octets (frame length /4/ and correlation id /4/) followed by 14 octets (throttle time /4/, error code /2/, fetch session id /4/ and count of following data sections /4/) subsequently followed by topic preamble.

Most times the response frames are sent as single packet (as long as they fit into IP packet), but the Fetch response frames are showing up split frequently enough to indicate some kind of network inefficiency.

The dumps were analysed with Wireshark built from the source code to leverage Kafka 2 dissection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)