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. Concurrency can be handled by pharo forks. 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.��
2016-12-14 15:11 GMT-03:00 Volkert <volkert@nivoba.de>:
> Pharo is currently successful used. Scalability and Performance will always
> an issue. I like Pharo really, but i have not to goal ending up in a complex
> deployment of Pharo Nodes, because a Pharo with Seaside can only handle -
> say 20 user - ...
The 20 user depends more on the I/O than anything else.
However you can scale Seaside horizontally using a front reverse proxy
like nginx using session affinity.
Memory is cheap, and the only limit now is CPU, the current Pharo
image has an idle CPU consumption ~5%, so you can't have many
concurrent images running in the same machine.
Regards,
Esteban A. Maringolo