Confirm multi-core support with data per test

[zarianec]

The probe server must utilize all available CPU cores.

Yes, I wanted to use throng for clustering but it means that every single probe will create multiple separate ws clients.

Originally posted by @zarianec in jsdelivr/globalping#37 (comment)

Alternative by Patryk https://nodejs.org/docs/latest-v12.x/api/worker_threads.html

[jimaek]

each command execution spawns a separate process,
the master process just handles the connection to the server and passes data back and forth
so this task can be closed imo
as long as we spawn a new process per command its done

[patrykcieszkowski]

each command execution spawns a separate process,
the master process just handles the connection to the server and passes data back and forth
so this task can be closed imo
as long as we spawn a new process per command its done

@zarianec It might make sense to run output parsers in worker threads, but I wouldn't worry about HTTP I/O, and ofc we don't have to worry about native commands since they run on separate processes already.

[jimaek]

Note to correctly handle native HTTP tests as well that dont call a binary jsdelivr/globalping#91

[patrykcieszkowski]

@jimaek as explained - it’s done

[jimaek]

Even HTTP (got)?

[patrykcieszkowski]

HTTP is an I/O request - it’s asynchronous like web sockets are. It’s not recommended to run I/O requests on separate threads, since native aync mechanism is much more performant. I’ve also proven this on my benchmark test cases.

https://github.com/patrykcieszkowski/node-io-benchmark

https://nodejs.org/api/worker_threads.html#worker-threads

[jimaek]

@zarianec let us know what you think and if the task can be closed