all 3 solutions have their caveats.

of course you can get a node_cluster to block, no, prob.

the service process is a different kind. it's master-worker system where 
master just recieves messages and queues them up and respondes to clients, 
and workers are fetching job requests from master, calculate and notify 
when done. the master is still responsive, because it just handles IPC I/O 
and manges the queue-based dispatching. the works block their own 
eventloop, but it's ok because they are detached from the rest of the app. 
it's similar idea like threads, but better to distribute over physical 
machines and the creation cost is paid on startup once. in fact you can use 
threads to implement the worker, but as fully detached process you can 
distribute even the worker.

to be honest, IF i have an app with high traffic, then i don't want the 
whole machine doing anything else but to handle this traffic, that's the 
case where threaded solution may reach it's limits. of course you can scale 
the whole thing horizontally. it's a decision to make depending on the 
requirements.

PS: i didn't say threads are bad, or threads-a-gogo. i just say there are 
cases, and they aren't rare, where threads are not good (enough). thats 
all. 

Am Freitag, 15. Februar 2013 11:29:03 UTC+1 schrieb Jorge:
>
> On 15/02/2013, at 10:02, greelgorke wrote: 
> > 
> > Am Freitag, 15. Februar 2013 07:08:44 UTC+1 schrieb Jorge: 
> >> On 14/02/2013, at 20:28, Jacob Groundwater wrote: 
> >> > 
> >> > I think the solution to any CPU intensive task is a work queue. Do 
> not mix your IO-bound processes with your CPU-bound processes. Node doesn't 
> suck at CPU-bound tasks, it just can't do IO at the same time. 
> >> 
> >> But a node with -javascript- threads *can* do IO *and* CPU-bound tasks 
> at the same time. 
> >> 
> >> > It's not like a threaded app will magically have more CPU to compute 
> with. 
> >> 
> >> Yes it will, in an N cores machine, a node with N threads has ~ N times 
> more CPU to compute with. 
> >> 
> >> Even in a single core machine, a node with threads-a-gogo can do any 
> amount of -javascript- CPU-bound tasks *and* any IO in parallel, easily and 
> without sttutering, something that no node can do without threads-a-gogo. 
> >> 
> >> <https://github.com/xk/node-threads-a-gogo> 
> > 
> > threads-a-gogo and node cluster are only 2 possible solutions. 
>
> Node cluster is a completely different thing because a node with any 
> number of heavy cpu-bound tasks running in threads-a-gogo will keep 
> processing any IO requests *IN*PARALLEL* just fine, but in a node-cluster, 
> any node that happens to be running a heavy cpu-bound task will be 
> completelly stalled and unable to do *ANY* IO until the task has finished. 
>
> For example, say you're serving a page A which is computationally heavy 
> and  takes 10 seconds to process, and a page B which isn't: 
>
> -with threads-a-gogo: no matter what, page B will always be served fast. 
> -with a node cluster: page B will only be served fast IF there's not any 
> pending request for a page A. If there's any previous request for a page A, 
> page B *and* any other pending IO will have to wait until page A is 
> finished. 
>
> Say you make a node-cluster with 4 nodes, and you get these requests in 
> this order: 
>
> a-a-a-a-a-a-a-a-b 
>
> B will take ~ 20 seconds! 
>
> Now say you instead .create() 4 threads with threads-a-gogo: B won't have 
> to wait for any As, it will be served immediately! 
>
> IOW: node-cluster does NOT give node the ability to run your code in 
> parallel with the event loop and thus as soon as your code blocks it stalls 
> node completely, UNLIKE the case of a node with threads_a_gogo. 
>
> > also you can put your heavy calculating routine in a separate module 
> which runs in a separate process and handles a queue and a worker pool. 
> fork it and comunicate via process#send. it's a system-internal service 
> process. 
>
> The thing is that when your code blocks the event loop the node process 
> stalls so you can't communicate with it. 
>
> To run blocking code and NOT stall node, the only sane solution is 
> threads-a-gogo, not node-cluster. 
>
> <https://github.com/xk/node-threads-a-gogo> 
> -- 
> Jorge.

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to