2016-12-14 15:41 GMT-03:00 Dimitris Chloupis <kilon.al...@gmail.com>: > That 5% idle CPU consumption is not the only problem, creating a new process > will add additional overheads anyway so it does not make sense to have more > pharo processes than CPU cores.
Not exactly, thinking it that way would disable you from running Pharo in a machine with other daemon services running (if daemons > cores). But those other daemons at idle consume less than 1% of the total CPU, whilst 10 idle Pharo images will consume 50%. With peak demand a single image can take 100% of the CPU core. > Concurrency can be handled by pharo forks. A Pharo forked process is still running under the vm single threaded process... so it's more a matter of in-image blocking rather than external access. > I am not web dev even by a remote imagination but my recent experience with > UFFI is that Pharo can go to insane speeds when it relies on C libraries , > especially performance orientated ones. Of course learning C and playing > with C is a pain by itself but necessary evil if top performance is the > goal. This is true. And non-blocking callbacks really alleviate the weight a single threaded vm can support. However any CPU intensive request will block the process, and that will happen with looping server like Pharo or an evented VM like NodeJS. Unless you're targeting to an initial really high concurrent users count, then you can scale up gradually. Esteban A. Maringolo
