>>Node uses single application thread and uses ansynchronous scheduling to IO bound operations to distributed load....
>
>Thank you for your that explanation, Rick. Most helpful and thought provoking. This very clearly clarifies the position of node.js from a strategic point of view, exactly what I was trying to find out.
>
>Sounds to me like node.js may be a good fit for dealing with simple AJAX requests as long as they don't involve any complicated processing. Of course the next thought, bearing in mind this is quite a major drawback, is whether node.js could become multi-threaded in a future version? This wouldn't mean leaving the whole Async paradigm behind, just allowing it to be configured to run multiple separate instances of node.js at the same time.

This sounds counter-intuitive but node.js actually IS very, very scalable for small transactional requests. In fact it scales better in that scenario than traditional Web backends because it is relatively light on server resources and you can spin up multiple instances to handle more load. But it simply is not good at CPU bound processing. It's extremely good at I/O bound processing. Anything that is I/O bound can be done asynchronously which leaves teh Web Server with free resources while it waits for the aysnc I/O tasks to complete. Typical applications have 90% + of I/O so what little is left can easily be processed with pre-emptive multi-threading.

All that said it leaves node as a good solution for a number of scenarios - basically any I/O heavy operations, or really small burst of CPU bound operations like short atomic inserts or reads from a database. What it won't be so good is as producing a large HTML document, or run a report doing complicate calculations on data in JavaScript code. For computationally intensive processing node.js either offloads to some sort of Web Service call, or the app simply calls traditional server backends to do that sort of processing.

Like I said - it's not a one stop solution but it's a good thing to mix into existing applications where scalability matters.

+++ Rick ---

>
>Could even make the number of live threads dynamic based upon server load - that was how I managed load when I was working on writing a VFP HTTP webserver, it changed both the number of instances of live requests allowed within each worker thread and the number of separate worker threads (each a separate .exe) based on the previous 30 seconds of load.
>
>Nick