Single threaded ie no concurrency is an option for concurrency - right ? And these still achieve concurrency eg multiple node.js servers on a single machine. It just has nothing to do with the language / runtime..
Ben On Thu, Aug 1, 2013 at 12:41 AM, David Jeske <[email protected]> wrote: > > 3) Fully async node js style with call backs > > I thought we were talking about concurrency. This model is single threaded. > > Here is a very high performance web concurrency model used prevalently at > big Internet shops I've worked at... > > a) one big async I/O "dumb spooler" (either on-machine, or as a remote > proxy) --- this is basically offloading the work of buffering/spooling for > slow-clients, so your workers can free up as fast as possible. Sometimes it > does other http-connection related optimizations. > > b) one worker-thread per end-user request-handler, spawned 1-4x per core, > depending on workload --- threads instead of async, because it's too easy > to lock-up an async core and create a cascade failure for any contended > resources (db locks, cursors, etc, etc). The spooler in (a) means this > thread is finished as fast-as-possible and not dependent on the client > accept rate. It finishes and moves onto new work before the spooler > finishes. > > c) async I/O core per worker-thread, to overlap calls to backend-servers > --- this avoids worker latency becoming an additive/serial combination of > backend-calls without the overhead of a thread-stack per overlapping > network RPC request. Sometimes this done with threads instead of async, > because modern machines can handle a crapload of threads, especially if > there are legacy synchronous/blocking network RPC libs. > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
