Re: 3 different architectures - best perfromance and redudancy?

[Michael Douglass]

An interesting aside, since you mention context switching... I spoke with Mikael at the breakfast yesterday morning about maximum cluster sizes in terms of the number of ndbd nodes. He stated, and this is based on my non-ECC brain material's memory, that on a 72-way sun he had what he considered "perfect" performance running 64 ndbd nodes on that box with shared memory as the transport and, one of the keys, using Solaris' ability to tie each of the ndbd processes to a processor such that it is the only process running on that processor. This would remove context switches and the associated overhead from that side entirely.

However, doing that to your mysql processes would be entirely silly... Remember that mysql is threaded, highly threaded; don't limit yourself to one processor there. Unless you like round holes and square pegs.

Another aside about the transport methods... Mikael mentioned that the performance with the same 64 node ndbd on the 72-way sun was definitely not very nice when using tcp/ip as the transport between the nodes. Which makes sense -- shared memory is going to be much faster than tcp/ip on same-machine conversations. A question comes to mind (now, while Mikael is on a plane) is what that means for building out large multi-machine clusters of ndbd backends. I know the SCI guys are hip on pushing their "low latency" product for this purpose. It'd be fun to see some numbers of various numbers of backends, different transport methods, etc. Of couse, that being said, I'd much rather the MySQL guys focus on continued development than cool, fun numbers that are only interesting from a pure geekhood standpoint today. I'm sure marketting will have some fun numbers for us in the wake of 5.0 going GA.

MikeDoug