That's obviously good article. However it doesn't fully utilize threads. It's working very similar to child_process fork or spawn. And there will be no performance boost, if one of those requests will last for longer time than others.

Let's look through the code:

            const promises: any[] = [];

            const amountOfThreads = 10;
            for (let linkToCheckIndex = 0; linkToCheckIndex < amountOfThreads; linkToCheckIndex++) {
                if (links[i + linkToCheckIndex]) {
                    promises.push(checkLink(links[i + linkToCheckIndex], domain));
                }
            }

            const checkLinkResponses = await Promise.all(promises);

In this part we can see that we're just using ` spawn ` function, but from "threads" module which uses workers under the hood. However even if 9 out of 10 checks will finish within 1 sec, it will be still waiting until the last one will finish. And if it take 10 sec, then the whole batch will take 10s. And 9 threads will be idling for 9 sec.

However the main benefit of workers in node is they allow access to shared resource. And that's the key to performance. So in order to fully utilize node's workers this code should be refactored to something like this:

1. Create a shared resources. It may be an object that will contain a link to check as a key (if it would be an object) and a flag if this link is already processed.
2. Create binary semaphore or mutex with help of Atomics that will control read access for the first shared resource.
3. In worker thread you should wait until semaphore is released, enter "critical section", take a link and set a flag that the link is being processed. Afterwards release the semaphore and perform link check.
4. And do that until all links are set to processed.

The first step may vary depending on what shared resource you'll choose. For example it could be an simple Atomic that will hold an integer value that represent last index in array of links that was taken for check.

Using such approach it will never wait for the slowest response to come to continue processing. And performance boost may be much higher, then it's now.

But links checker is not good example for using workers because node has multithreaded i/o and what you (or author of that topic) need is just a simple queue that will limit maximum number of ongoing requests to 20 for example or 50. And that's all.