3 ms·
The crux of the difference seems to be, in the Node.js service: "when any request timeouts happened, the event and its associated callback was put on an alread
by firasd 11y ago
The crux of the difference seems to be, in the Node.js service:
"when any request timeouts happened, the event and its associated callback was put on an already overloaded message queue. While the timeout event might occur at 1 second, the callback wasn’t getting processed until all other messages currently on the queue, and their corresponding callback code, were finished executing (potentially seconds later)."
And in Go,
"the service has a worker pool and a delegator which passes off incoming jobs to idle workers. Each worker runs on it’s own goroutine, and returns to the pool once the job is done."
- awjr 11y agoNode.js has cluster to solve this issue https://nodejs.org/api/cluster.html#cluster_cluster https://nodejs.org/api/cluster.html#cluster_cluster
- Sanddancer 11y agoWhich brings us back to 2001 and Apache's prefork model. Threads are pretty battle tested at this point, and allow for different reasoning about the concurrency of a problem. The problem with node is that it pretty much only allows for one type of scaling if you start running into performance problems. Go gives you a much bigger toolbox to work with if, much like the post's author discovered, your problem set does not match up with the answers node provides.
- qaq 11y agoAll is well until you have to deal with SEO for SPAs :) and then there is little choice other then node. https://github.com/audreyt/node-webworker-threads https://github.com/audreyt/node-webworker-threads spawn real threads with web workers compatible API.
- lenkite 11y agoThis is the first solution that a boring 'enterprise' Java programmer would have used and got on with other work.