krishvishal opened a new pull request, #4502: URL: https://github.com/apache/iggy/pull/4502
Relates to #3560 Produce through the gateway was slow because of three things in the gateway itself, not in Iggy. This fixes them. ### What changed - TCP no-delay on every Iggy client the gateway opens. A send bigger than the SDK's 8 KiB write buffer goes out as two writes, header then payload. With Nagle on, the payload waited for the server's delayed ACK, about 40 ms per send - one Iggy client per producer. Before, every Kafka connection shared one client, and only one Produce send was in flight for the whole gateway. Now a producer waits only behind its own sends, which also keeps its batches in order - the Produce limit counts bytes. It was 4 requests at once whatever their size, and small requests queued behind each other's Iggy round trip. Total memory is the same as before, about 160 MB at the default 8 MiB frame ### Producer sessions - a producer is the producer id of the request's first batch. If the batch has none, it is the Kafka connection - a session connects on its first send - up to 256 stay open. Opening a new one closes the free ones idle for 10 minutes, then the least recently used free one. If all 256 are busy the request answers 7 - a stuck send holds only its own session, 45s at most. That producer's later sends answer 7 meanwhile and can't overtake it. Other producers keep sending - Metadata and CreateTopics still share one client ### Produce limit - a request holds what its largest partition can decode: its bytes, or 64 bytes per declared record if that is more. A compressed partition holds a whole partition cap, because it can grow to that - a request of 64 KiB or more takes one of 4 large slots first, and holds no memory while it waits. Without this cap the 1 MiB requests of 12 producers all ran at once at full load. That cost about 27% more gateway CPU per MB, and throughput went up and down between runs - past its deadline waiting for either: 7, same as before -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
