4 ms·
"My understanding was that you actually have to be careful not to write code that runs for too long, in order to avoid messing up your request times by ruining
by grimlck 16y ago
"My understanding was that you actually have to be careful not to write code that runs for too long, in order to avoid messing up your request times by ruining the cooperative scheduling scheme used in the language."
That is my understanding as well - because a long running task will block everything, you have to be MORE careful in node.js than in a traditional threaded environment. I actually think that this model works really well in 10% of applications, and a threaded model is a better choice in 90% of applications.
I also believe 'less mature developers' see, 'wow, server side javascript', get excited by that, and don't put enough attention on the more important architectural differences of node.js
- arethuza 16y agoAre there any "traditional" server side JavaScript environments?
- arethuza 16y agoI did find this: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS... which I will probably work through at some point, I'd really like to use JavaScript on the server but I'm not sure if node.js is a good fit.
- cdavid 16y agoYes, this is a real pain point, because that's exactly why you need everything to be non-blocking in the libraries you are using with something like node.js (things like twisted in python have exactly the same issue). Not only do you need non-blocking code for things like database access, but maybe more subtly, you need to be non-blocking for anything which is potentially CPU heavy. Case in point: encoding a payload in say xml or json. If you have a response which are big enough that they need say 20 ms to encode, all response whose processing have started but not yet finished will see a 20 ms additional delay. Now, you can incrementally encode into json by inserting new "scheduling points" at regular intervals, but doing this for say zlib compression, not so easy. Not that I have a lot of experience, but IMO, async code should be reserved to the least amount of code possible, because everything becomes a bottleneck. And good luck trying to profile your async application with all those callbacks when you have performance issues...