> I think what you're seeing is a micro benchmark effect, that is all you're >> measuring is how fast messages can be sent, which is very fast but could >> easily depend in some way on the number of workers. > > > Well the question I'm asking here is WHY the send rate would depend on the > number of workers, even when you pin them to different CPUs. This is all on > recent kernel, new CPUs, fast machines. The send rate changing based on > number of workers makes no logical sense so I'm trying to establish why > this happens. >
Off the top of my head (without bothering to dig into the code): - there's some O(N) operation in node relating to number of workers like looking them up in an array - the operating system is introducing latency, e.g. due to context switching or paging. Have you tried tracking all the potentially relevant system performance stats in parallel with your runs to see if any of them spike? I'm curious why sending messages is the key performance metric? The reason I suggested an alternate benchmark is because the difference between sending 220K/s and 180K/s would only seem to matter if the receiver could somehow do more net work at the higher rate. I'm struggling to imagine what task it could perform that wouldn't make that difference immaterial. -- -- 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.
