May not be relevant but testing on Win7 4-core showed some odd
memory behavior, 1 process would be taking a lot of heap, sometimes the
master but not always. Looked like results were not stable because of this
growth. Tested on v0.8.19.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidel
On Wed, Mar 20, 2013 at 9:31 AM, Arnout Kazemier wrote:
> I'm only logging the send rate. I don't care what the workers receive. I
> would expect the send rate to be constant since the master is always doing
> the same amount of work.
>
> Why would you expect that? Each worker you add send more m
On Wed, Mar 20, 2013 at 9:41 AM, Ben Noordhuis wrote:
> You don't. If the machine has 12 HT CPUs, you should test with (12 /
> 2) == 6 processes.
>
That doesn't explain the results I got:
I tested with two workers, using taskset -p 1 on the master, 4 on worker 1,
and 16 on worker 2. Wouldn't t
On Wed, Mar 20, 2013 at 2:26 PM, Matt wrote:
> On Wed, Mar 20, 2013 at 8:34 AM, Ben Noordhuis wrote:
>>
>> What numbers are you seeing? large_number / number_of_workers is what
>> you should expect to see: a fairly constant total throughput with
>> per-worker throughput inversely proportional to
> I'm only logging the send rate. I don't care what the workers receive. I
> would expect the send rate to be constant since the master is always doing
> the same amount of work.
Why would you expect that? Each worker you add send more messages to the master
process and there for making it slowe
On Wed, Mar 20, 2013 at 8:34 AM, Ben Noordhuis wrote:
> What numbers are you seeing? large_number / number_of_workers is what
> you should expect to see: a fairly constant total throughput with
> per-worker throughput inversely proportional to the number of workers.
>
In case my description was
On Tue, Mar 19, 2013 at 8:54 PM, Matt wrote:
> I created a simple script to test cluster's performance sending messages to
> workers.
>
> My problem is it slows down the send() rate significantly as I add workers,
> starting at 1 worker being the fastest. I would expect the send() rate to be
> com
I created a simple script to test cluster's performance sending messages to
workers.
My problem is it slows down the send() rate significantly as I add workers,
starting at 1 worker being the fastest. I would expect the send() rate to
be completely untied to the number of workers (at least until y
