Topic starter
18/08/2026 2:42 pm
TL;DR: AxoSyslog pipelines can lose throughput without crashing when log-iw-size(), batch-lines(), and worker queues are misaligned, because in-application ACKs determine how many messages can stay in flight, according to Axoflow. The practical lesson is that window sizing, buffering, and batching must be tuned as one system, not as isolated knobs.
Editorial analysis by NHI Mgmt Group, based on content published by Axoflow: “AxoSyslog internals: flow control, window size, queues, and batching”.
Key questions
Q: What breaks when log-iw-size() is too small for batching?
A: Partial batches keep flushing before they fill, so the pipeline spends more time waiting on batch-timeout() than sending efficient batches.
Q: Why does max-connections() affect AxoSyslog throughput even when traffic is steady?
A: Because the source window is divided across connections, a high max-connections() setting can shrink the per-connection share enough that workers cannot gather enough messages to fill batches.
Q: How do security teams know batching is being starved by the window rather than by the source?
A: Look for a pattern where messages arrive, but destination workers repeatedly flush small batches after waiting for batch-timeout().
Practitioner guidance
- Size log-iw-size() against active fan-out Set the source window to cover the number of active connections, destination workers and target batch size, not the maximum possible connection count.
- Prefer dynamic-window-size() for spiky connection counts Use dynamic-window-size() when max-connections() is much higher than the usual number of active sessions so that idle connection slots do not waste in-flight capacity.
- Use disk-buffer() when batching is starved Switch to disk-buffer() when partial batches and repeated batch-timeout() flushes show that the memory queue cannot hold enough messages to fill batches.
Bottom line: AxoSyslog can remain operational while still underperforming badly if the message window is too small for its batching design.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:25 pm
Throughput collapse in log pipelines is usually a governance problem, not a transport problem. The article shows that a pipeline can remain up while still operating below its expected capacity because windowing and batching are misaligned. That matters because security teams often watch for outages, not for silent under-delivery. The control failure is a sizing assumption that treats throughput as incidental rather than governed.
A question worth separating out:
Q: Should teams use disk-buffer() or tighter window tuning first?
A: Tighten the window first if the goal is efficient batching under memory buffering, because that exposes whether the source window is the real bottleneck. Use disk-buffer() when durability or decoupling matters more than preserving a strict end-to-end ACK chain.
👉 Read our full editorial: AxoSyslog flow control and batching can cap pipeline throughput