I’m using Luigi Berrettini’s NLog.Targets.Syslog package in one of my projects to log from a set of containers to a centralized syslog server, and I noticed that when one of the containers in my application had a sudden spike of logged messages, they were taking a very long time to reach the syslog server.

A bit of research brought me to this closed issue in the project’s repo, and this question that the author posed to Microsoft in relation to the issue. I think the first link explains the problem pretty well but long story short, it turns out that if you configure the NLog target using the UDP protocol, default settings in the library make it so messages get dequeued to be sent through the UDP socket at a rate of 2 per second. The rationale behind the code that has this effect was to try to minimize message loss if the UDP destination wasn’t there, but IMO the performance impact is a bad trade-off. And since the nature of UDP means that package loss is a possibility, I’d rather know that some of my messages might get lost, but have better logging throughput out of the box.

The fix to improve this throughput is pretty easy, just add a connectionCheckTimeout attribute to the target/messageSend/udp element in the nlog.config file, with a low value (0 being a possibility).

<target xsi:type="Syslog" name="syslogTarget">
  <sl:layout xsi:type="SimpleLayout" text="${message}" />
  <sl:messageSend>
    <sl:udp server="127.0.0.1" port="514" connectionCheckTimeout="0" />
  </sl:messageSend>
</target>

This value (in microseconds) controls the timeout that the target uses when trying to decide if data can be sent on the socket, a check it does for every message. So decide if you want anything other than 0 here, update your nlog.config, and enjoy your improved throughput!