Bump akka to 2.6.16
[controller.git] / akka / repackaged-akka-jar / src / main / resources / stream_reference.conf
index dd982714a17af35b7ec03f13818a4a97be70dff9..66d9130e38a46a893496965a37531334be0f3c2b 100644 (file)
@@ -87,6 +87,39 @@ akka {
         # slightly more bytes than this limit (at most one element more). It can be set to 0
         # to disable the usage of the buffer.
         write-buffer-size = 16 KiB
+
+        # In addition to the buffering described for property write-buffer-size, try to collect
+        # more consecutive writes from the upstream stream producers.
+        #
+        # The rationale is to increase write efficiency by avoiding separate small
+        # writes to the network which is expensive to do. Merging those writes together
+        # (up to `write-buffer-size`) improves throughput for small writes.
+        #
+        # The idea is that a running stream may produce multiple small writes consecutively
+        # in one go without waiting for any external input. To probe the stream for
+        # data, this features delays sending a write immediately by probing the stream
+        # for more writes. This works by rescheduling the TCP connection stage via the
+        # actor mailbox of the underlying actor. Thus, before the stage is reactivated
+        # the upstream gets another opportunity to emit writes.
+        #
+        # When the stage is reactivated and if new writes are detected another round-trip
+        # is scheduled. The loop repeats until either the number of round trips given in this
+        # setting is reached, the buffer reaches `write-buffer-size`, or no new writes
+        # were detected during the last round-trip.
+        #
+        # This mechanism ensures that a write is guaranteed to be sent when the remaining stream
+        # becomes idle waiting for external signals.
+        #
+        # In most cases, the extra latency this mechanism introduces should be negligible,
+        # but depending on the stream setup it may introduce a noticeable delay,
+        # if the upstream continuously produces small amounts of writes in a
+        # blocking (CPU-bound) way.
+        #
+        # In that case, the feature can either be disabled, or the producing CPU-bound
+        # work can be taken off-stream to avoid excessive delays (e.g. using `mapAsync` instead of `map`).
+        #
+        # A value of 0 disables this feature.
+        coalesce-writes = 10
       }
 
       # Time to wait for async materializer creation before throwing an exception