uWebSockets.js: Linux vs Windows Performance

[gjovanov]

We tried to benchmark simple non-async ping API on both Linux Ubuntu 20.04 and Win 10 using this example:

const uws = require('uWebSockets.js')
const port = 4001

const app = uWS.App({})
.get('/api/ping', (res, req) => {
  res.end('pong')
})
.listen(port, (token) => {
  if (token) {
    console.log('Listening to port ' + port)
  } else {
    console.log('Failed to listen to port ' + port)
  }
})

The same code from above, was run on the same laptop (hardware), whereat Ubuntu 20.04 was a WSL installation and WIN 10 is the default laptop OS, hence it doesn't make sense to provide hardware specs. In both tests, these were running on the same hardware.

First of all, an awesome performance was achieved on Linux (Ubuntu 20.04):

wrk -d3 -t1 "http://172.19.44.18:4001/api/ping"
Running 3s test @ http://172.19.44.18:4001/api/ping
  1 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    78.21us   48.84us   1.04ms   88.24%
    Req/Sec   133.83k    18.82k  153.45k    87.10%
  411816 requests in 3.10s, 21.99MB read
Requests/sec: 132838.26
Transfer/sec:      7.09MB

Compared to running it on Windows 10:

wrk -d3 -t1 "http://172.19.32.1:4001/api/ping"
Running 3s test @ http://172.19.32.1:4001/api/ping
  1 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   368.16us   82.98us   1.40ms   72.65%
    Req/Sec    27.01k     1.65k   30.07k    64.52%
  83246 requests in 3.10s, 22.39MB read
Requests/sec:  26858.59
Transfer/sec:      7.22MB

I wonder why is Win 10 so sluggish and offers such a huge degradation in req/sec?

Is it NodeJs on WIN thing? Is there anything it can be done, to improve the results on Win 10?

My assumption is because wrk is installed on WSL 2 - Ubuntu 20.04 so when running the first test (Ubuntu), we are not hitting the network, whereat, when we run the second test, we have to hit the network, because of WSL 2 - Ubuntu being on a different subnet IP than the WIN 10 host ip.

Unfortunately, since are not able to install wrk directly on Win 10, but we have to use WSL 2 instead, there is no way to test this assumption?

Any suggestion to prove our assumption wrong or correct, and if there is anything we can do to reach the benchmark results similar to those on Ubuntu?

Or we just need to accept, that Win 10 sucks 😄 and there is nothing we can do about it?

Your input is highly appreciated.
Thanks.

[ghost]

Windows 10 doesn't suck (in this context), but doing benchmarks with WSL2 is most probably very wrong. Not only is WSL2 virtualized, it also has virtualized NICs and all kinds of crap attached to it - especially between Windows world and Linux world (from what I understand, I an no expert in WSL2 so I can be wrong).

[gjovanov]

Makes total sense.

Thanks for your input.

[ghost]

A rule of thumb can be to assume Linux to be the production platform and Windows to be second-class platform. It doesn't have to be like this, but that's a good rule of thumb since we really only benchmark on Linux (and sometimes on macOS or FreeBSD).

[gjovanov]

It's not a dev on WSL, but a Win 10 dev. Unfortunately, the client of ours, has an app as well as infrastructure, heavily bound with Windows and Microsoft related products (mssql replication, sso etc etc), so we were evaluating swapping their current dotnet + signalR solution by uWebSockets.js. In order to run benchmarking we only installed wrk via WSL2 and that's how we noticed this perf degradation. So then goal is to use uws on Win10 and still show the client the nice benchmark results uws provides on linux. But is seems that its not a proper way to run wrk from WSL against uws running on win10.

…

On Wed, Apr 21, 2021, 18:46 hst-m ***@***.***> wrote: you should not be developing on WSL you should be running full virtual machines like virtualbox etc to fully simulate a production environment, otherwise you get issues like this guy #467 <#467> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#515 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARGUS6UCG6ARNPWPSCMLBLTJ3XMJANCNFSM43KSF2DA> .

[ghost]

Run uws natively on Windows and connect a point-to-point Ethernet cable to a native Linux box that runs the client using many threads.

[ghost]

You can also just look at CPU-time utilization at whatever number and extrapolate linearly from that. I get like 4% CPU-time utilization on Windows over Wifi at like 30k req/sec so similarly you can scale it linearly as a guesstimate.

[OmgImAlexis]

Hoping this is the right place to post this, for those that using WSL to dev be warned you'll only ever get 0000:0000:0000:0000:0000:0000:0000:0001 back for getRemoteAddressAsText and getRemoteAddress will return an empty string.

Here's a small example I tried on WSL. Running it on windows/linux, etc. no issues. Going to take a guess something to do with the virtual nic WSL uses.

const uWS = require('uWebSockets.js');
const port = 9001;

uWS.App().get('/', (res, req) => {
  res.end(JSON.stringify({
    getRemoteAddress: Buffer.from(res.getRemoteAddress()).toString(),
    getRemoteAddressAsText: Buffer.from(res.getRemoteAddressAsText()).toString(),
    getProxiedRemoteAddress: Buffer.from(res.getProxiedRemoteAddress()).toString(),
    getProxiedRemoteAddressAsText: Buffer.from(res.getProxiedRemoteAddressAsText()).toString()
  }));
}).listen(port, (token) => {
  if (token) {
    console.log('Listening to port ' + port);
  } else {
    console.log('Failed to listen to port ' + port);
  }
});

[OmgImAlexis]

@e3dio I'd rather not use a tiny AWS instance when I have a more than capable local machine here. Just pointing this out.

[OmgImAlexis]

your Windows machine will restart itself every couple days and opens your computer up to the internet.

Completely incorrect. If you don't know what you're saying don't bother commenting.