3 ms·

> And if you're going to solve that problem by running each service in its own container or VM then again that only makes the context switches heavier [...] Qu

by vemv 5y ago

> And if you're going to solve that problem by running each service in its own container or VM then again that only makes the context switches heavier [...] Quite obviously I meant running a microservice / job processor in a different "node" (aws instance, whatever). It barely makes sense to let microservices compete with each other for CPU - one precisely seeks greater isolation. > Well no shit if you just buy more CPU cores whenever you want to run more code then you don't need to worry about getting decent performance out of your hardware. Large codebases relate strongly to large businesses that can afford hardware matching their scale. > I guess when you add the 129th function to your codebase you then throw away all your super-expensive servers and buy even more expensive 256-core replacements? Ok I regret spending time over your replies.

lmm 5y ago
> Quite obviously I meant running a microservice / job processor in a different "node" (aws instance, whatever). That's still just sweeping the problem under the carpet. Either you're getting a physical core for each function, in which case you're paying for lots of cores. Or you're multiplexing functions onto cores at some level (whether that's your own code, shared hosting, AWS lambda, or whatever) in which case someone (you or your service provider) is doing a bunch of context switches that have to be paid for somehow. > It barely makes sense to let microservices compete with each other for CPU - one precisely seeks greater isolation. For services big enough to need a full CPU (or a full core) all the time, you may as well give them a full CPU. But that implies a much coarser level of granularity than you've been suggesting. If your services really are "micro" then it makes a huge amount of sense to share a CPU between multiple services because most of them don't need a whole CPU the whole time. > Large codebases relate strongly to large businesses that can afford hardware matching their scale. The code grows faster than the hardware use. I've worked on codebases that were deployed on thousands of machines - but they had millions of lines of code and tens if not hundreds of thousands of functions. One of them even did take the approach of running multiple steps of the same logical computation on separate machines - but this was still done by having a yield point in the code and a scheduling framework that dispatched tasks onto grid compute machines, both because even though the code gets compiled into a state machine representation (i.e. one-way flows, de facto unstructured programming - the same as your pipeline approach) you don't want to have to maintain it in that form, and even if you did have code that looks like that, manually deciding how many cores to allocate to processing each state would not have been tractable. > Ok I regret spending time over your replies. Look, I honestly thought you were doing some kind of elaborate troll. What on earth kind of environment are you working in where you have more cores than code?
kaba0 5y ago
That’s just somebody else’s computer but now with free network latency.

by vemv 5y ago

lmm 5y ago

> Quite obviously I meant running a microservice / job processor in a different "node" (aws instance, whatever). That's still just sweeping the problem under the carpet. Either you're getting a physical core for each function, in which case you're paying for lots of cores. Or you're multiplexing functions onto cores at some level (whether that's your own code, shared hosting, AWS lambda, or whatever) in which case someone (you or your service provider) is doing a bunch of context switches that have to be paid for somehow. > It barely makes sense to let microservices compete with each other for CPU - one precisely seeks greater isolation. For services big enough to need a full CPU (or a full core) all the time, you may as well give them a full CPU. But that implies a much coarser level of granularity than you've been suggesting. If your services really are "micro" then it makes a huge amount of sense to share a CPU between multiple services because most of them don't need a whole CPU the whole time. > Large codebases relate strongly to large businesses that can afford hardware matching their scale. The code grows faster than the hardware use. I've worked on codebases that were deployed on thousands of machines - but they had millions of lines of code and tens if not hundreds of thousands of functions. One of them even did take the approach of running multiple steps of the same logical computation on separate machines - but this was still done by having a yield point in the code and a scheduling framework that dispatched tasks onto grid compute machines, both because even though the code gets compiled into a state machine representation (i.e. one-way flows, de facto unstructured programming - the same as your pipeline approach) you don't want to have to maintain it in that form, and even if you did have code that looks like that, manually deciding how many cores to allocate to processing each state would not have been tractable. > Ok I regret spending time over your replies. Look, I honestly thought you were doing some kind of elaborate troll. What on earth kind of environment are you working in where you have more cores than code?

kaba0 5y ago

That’s just somebody else’s computer but now with free network latency.