Proposal: lets get rid of the non-thread code

[Dirk-Willem van Gulik]

On Feb 7, 2008, at 9:30 PM, dormando wrote:

>> Has anyone compared it to running as many separate non-threaded  
>> instances as you have processors?
>
> That's how it was done originally. The idea of threading it is to  
> get greater memory efficiency, and higher efficiency of multi-get  
> requests. IE; box has 64G of RAM, but you'll peg a single CPU before  
> using all of it, but your code does tons of mgets and it sucks a bit  
> to poll multiple memcached's for the data.

My experience though is that, multithreaded, on Solaris/FreeBSD/Linux  
it will comsume some around 5, 10 and 30% more CPU than when running  
as multiple thread v.s. single thread/process. And that having  
multiple processes or simply start multiple works fine on dual cpu  
dual core sort of levels. And when you fork or start more things split  
nicely*. In reality I've not seen this matter that much - as you  
generally try to keep 30-50% capacity overshoot on each memcached  
dedicated box in case one of the other(s) fails.

Not sure what happens on 8+ cores -- but given the cost of bandwidth  
to memory and the PCI card IO - propably not that relevant. (Esp. on  
linux where the interrupts from the PCI card can peg things  
essentially on one CPU).

So I'd only do this if you where very sure it was as good in virtually  
all cases and better in some. Which is something I've certainly not  
yet seen that clearly.

Dw

*: except when you see some core affinitiy propably due to the IRQ  
beeing handled there.