Yes, 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 (th

Yes, 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...