Windows Subsystem for Linux (WSL) is an optional feature of Windows 10 for developers who want the power of Linux (especially the Linux shell) on their Windows desktops. Of course, it is more than just a shell:you can easily install and run any command line applications (but not GUI). As a Linux desktop user, I do not need WSL to access a Linux shell, but as I am often asked how syslog-ng runs in WSL, I finally gave it a try.

The recurring questions are if syslog-ng runs at all in WSL and what the performance compared to syslog-ng installed on Linux is. As I run openSUSE Leap 15.1 as my main operating system on my laptop, I used that in WSL as well. I tested not just WSL 1, which has been generally available for years, but also the upcoming WSL 2, which brings tons of performance improvements. As WSL 2 involves virtualization, I also tested syslog-ng in Vmware Workstation running on Windows. In all cases, I used the latest syslog-ng 3.26 from my unofficial syslog-ng repository for openSUSE and a minimally modified syslog-ng.conf to enable the network source. Benchmarking was done both from localhost and from a small Xeon server on the local network, attached through Gigabit Ethernet.

If you want to test it yourself

WSL 1 has already been available in Windows 10 for years and is considered stable. WSL 2 has been available in the Insider Preview version of Windows for about a year now, but still not generally available, as it has a few rough edges. For benchmarking, I used the loggen utility, which is part of syslog-ng:

loggen --active-connections=10 -r 10000000 -i -S 514

The used parameters mean:

  • --active-connections=10 is the number of parallel connections to send logs

  • -r 10000000 is the maximum number of logs loggen attempts to send in a second

  • -i send logs over network

  • -S use TCP

  • IP address and port

By default, syslog-ng supports 10 parallel TCP connections on a TCP source. This can of course be changed, but I wanted to stay as close to an out-of-the-box syslog-ng.conf as possible. So I just took out a UDP source from comment, and replaced it with TCP. There is also an include, which does not work in WSL due to lack of proper service management. I replaced it with the results of the include. This is how the beginning of syslog-ng.conf looks :

source src {
        # use system() for local logs
        # syslog-ng's internal messages
        # uncomment to process log messages from network:
        tcp(ip("") port(514));
source chroots {};

This last change was only necessary in WSL, not when Linux was running on the host machine or in a virtual machine.

I repeated all tests three times, averaged them and rounded the results to the nearest ten thousand.

Base line

With a specially tuned configuration, syslog-ng is capable of collecting more than 800k messages per second on my laptop. But that is far from any real-life configurations. That is why I chose to stay with the default syslog-ng.conf of openSUSE and do only minimal changes to it. I ran the benchmark both from localhost and from an external host. The results were in both cases around 430kMsg/s.


The original implementation of WSL emulates Linux system calls on Windows, slowing down any IO operations considerably. As mentioned earlier, the main purpose of WSL is to provide Linux shell access to users. Focusing on quick shell access means that service management is missing completely from WSL. Once you start it, you get to the shell prompt in a fraction of a second, even faster than to Microsoft’s own PowerShell :) But it also means that you have to start syslog-ng yourself from the command prompt. As syslog-ng runs directly on Windows, it also uses the IP address of the host. When benchmarking from an external host, you can use both Linux and Windows tools to check which IP address to connect to.

Benchmark results were about 70kMsg/s both from localhost and from the external host. It is less than 1/6 of what is possible when syslog-ng runs natively on bare-metal Linux, but still two orders of magnitude more than most users need (the majority of users I talked to handle less than 500 messages a second).


As mentioned earlier, WSL 2 is not yet generally available. You need to run Windows Insider Preview in order to use it. Performance is a lot better, but there are still some limitations and rough edges. WSL 2 is already using virtualization and a real Linux kernel. This way, performance is a lot better and in theory there is just a minimal increase in resource usage. In practice, there are reports that RAM usage is constantly growing.

Unlike WSL 1, syslog-ng is running in a virtualized environment, so it cannot bind to the host’s IP address directly. Due to simplification, you cannot configure networking for the virtual machine, so it is always NAT with a random internal IP address. What this means is that you cannot reach syslog-ng from external hosts. This way, benchmarking is only possible from the localhost. While WSL 2 is not yet ready for the prime time, the results show that it is a good approach: 330kMsg/s, so almost 5x more than with WSL 1 and more than ¾ of native performance.

Vmware Workstation

Finally, I did a quick test using Vmware Workstation. As WSL 2 is using virtualization, I was curious how it compares to Vmware, what I normally use for virtualization. I quickly installed a trial version of Workstation and did a fresh install of openSUSE Leap 15.1 and syslog-ng 3.26. Compared to WSL 2, it is definitely slower to boot and also slightly slower collecting log messages. On the other hand, it is a properly installed system with service management, so you do not have to start syslog-ng from the command line or create custom hacks to start it automatically. Also, there are many network configuration possibilities, including bridge mode, where the network interface is bridged to the LAN. In this case, benchmark results from localhost and external hosts were different. From localhost I measured 290kMsg/s and from my Xeon server “only” 250kMsg/s meaning that networking has some overhead.

What is next?

As you can see, you can run syslog-ng in a WSL environment. It is not designed for running services, but it is not impossible :) If you want to add logging to your development environment in WSL, you can use syslog-ng. Some people even develop syslog-ng features in WSL. You can also use it to test syslog-ng configurations.

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at On Twitter, I am available as @PCzanik.

Related Content