many node vs single with eio.setMinParallel higher than 4

[am_p1]

So I'm seeing some queuing in my odbc to db2 path, I assume due to the note on node-odbc's npm page re 4 threads (pretty sure queuing not related to hardware right now).

The note also implies this area is changing with node 0.10 (I'm at 0.8.16).

I'm trying to determine some general rules of thumb when you should/shouldn't use multiple node's vs more threads with a single node.

My noobie take on this is (since running parallel is fine with my app/db design) to spread as many nodes wide as I need, until the hardware starts queuing somewhere.

Partly because child_process.fork says "That is, you cannot create many thousands of them", which implies to me I can create hundreds. :-)

[am_p1]

left out that ALL node's would be long running (started just once in the morning) so no startup/teardown overhead...

[am_p1]

ok, so apparently eio is gone and libuv is what i'm actually using (not knowing the history of node makes for a confusing day)

no wonder eio or eio-simple didn't work :-)

so I couldn't find any min/max controls on threads anywhere so i assume that if i'm seeing queuing, my only choice is another node (or child_process.fork) ?

thanks for the advice!!

[Ben Noordhuis]

On Thu, Jan 3, 2013 at 11:57 PM, am_p1 <andrewmc...@gmail.com> wrote:
> ok, so apparently eio is gone and libuv is what i'm actually using (not
> knowing the history of node makes for a confusing day)
>
> no wonder eio or eio-simple didn't work :-)
>
> so I couldn't find any min/max controls on threads anywhere so i assume that
> if i'm seeing queuing, my only choice is another node (or
> child_process.fork) ?
>
> thanks for the advice!!

Yes, libev and libeio are gone. libuv doesn't let you set upper or
lower bounds on its thread pool's size, it's supposed to Just Work.

Forking is a pretty good strategy; I would recommend it over mucking
around with thread pools.

[am_p1]

It's working great but odbc to db2 queues and backs up some. I assume because when using ps -eLf I can see that there are still only 4 threads per node and the number doesn't change.

Is the thread count suppose to change dynamically with libuv now?

[Ben Noordhuis]

On Fri, Jan 4, 2013 at 5:41 PM, am_p1 <andrewmc...@gmail.com> wrote:
> It's working great but odbc to db2 queues and backs up some. I assume
> because when using ps -eLf I can see that there are still only 4 threads per
> node and the number doesn't change.
>
> Is the thread count suppose to change dynamically with libuv now?

It will when v0.10 comes out. I was working on that just the other
day, actually.