26 ms·

When a request could block the server, for example a request which download or upload a big file, Node it not for you. Any concurrent language would be better.

When a request could block the server, for example a request which download or upload a big file, Node it not for you. Any concurrent language would be better. Node is perfect when a lot or requests work together, but each one in a small time or even a long time but step by step. that is my experience and I hope it will help to choose the right tool for the task.

regularfry 10y ago
That misses the point of the article, and misses what they learnt. The point isn't that a request was blocking the server. That's exactly not what happened. The point was that they couldn't handle the timeout of the non-blocking request they were making because there were so many other non-blocking events being processed before the timeout callback could be handled. They could probably have solved this by scaling out, but I'm not going to fault their diagnosis or response.
- chadscira 10y ago
  This could have been solved with a simple addition of another queue. Don't spawn off heavy requests without a throttle / queue, or else you will overload your single core. We normally don't think about this because most requests are just tiny queries / small http requests.
  - ericj5 10y ago
    This. It sounds like the author used a queue and worker pool with the Go version. There's nothing stopping you from doing the same thing in Node. I think a lot of people forget this sometimes and just spawn off unlimited multiple simultaneous requests in Node apps. Doesnt matter what language you're using, that's never going to turn out well
- mtberatwork 10y ago
  > They could probably have solved this by scaling out, but I'm not going to fault their diagnosis or response. Just want to add that EC2 instances aren't exactly cheap either when it comes down to it. I'm sure budgets are tight at Digg. Far better to first try to solve the problem with refactoring than throwing more hardware at it.
  - deleted 10y ago
    [deleted]

regularfry 10y ago

That misses the point of the article, and misses what they learnt. The point isn't that a request was blocking the server. That's exactly not what happened. The point was that they couldn't handle the timeout of the non-blocking request they were making because there were so many other non-blocking events being processed before the timeout callback could be handled. They could probably have solved this by scaling out, but I'm not going to fault their diagnosis or response.

chadscira 10y ago
This could have been solved with a simple addition of another queue. Don't spawn off heavy requests without a throttle / queue, or else you will overload your single core. We normally don't think about this because most requests are just tiny queries / small http requests.
- ericj5 10y ago
  This. It sounds like the author used a queue and worker pool with the Go version. There's nothing stopping you from doing the same thing in Node. I think a lot of people forget this sometimes and just spawn off unlimited multiple simultaneous requests in Node apps. Doesnt matter what language you're using, that's never going to turn out well
mtberatwork 10y ago
> They could probably have solved this by scaling out, but I'm not going to fault their diagnosis or response. Just want to add that EC2 instances aren't exactly cheap either when it comes down to it. I'm sure budgets are tight at Digg. Far better to first try to solve the problem with refactoring than throwing more hardware at it.
- deleted 10y ago
  [deleted]