2 ms·
There is hardly any "context switch" if you run one process per core There is hardly any context switch if I don't run any software at all on my server. Zero b
by buff-a 15y ago
There is hardly any "context switch" if you run one process per core
There is hardly any context switch if I don't run any software at all on my server. Zero bugs either. Back to the real world, and the point of this discussion, we run multiple Ruby processes per CPU so that when one process is waiting for the db or memcache, another can be doing useful work on the same CPU.
When using threads there is a much larger chance of introducing race conditions and deadlocks and other synchronization fails
As opposed to dropping the problem into memcache and getting it wrong: your code "works", you get no crashes, but customers lose data, lose posts, or lose money. If you're advocating using memcache because multithreading is too hard for your programmer, then your customers are fucked.
- wladimir 15y agoWe run multiple Ruby processes per CPU so that when one process is waiting for the db or memcache, another can be doing useful work on the same CPU That's the trivial case. When waiting for the db or memcache (I/O in general), the GIL is lifted, so it doesn't get in the way. It only gets in the way if multiple threads are inside the ruby VM doing work.