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.
On Wed, Dec 14, 2016 at 8:28 PM Esteban A. Maringolo <emaring...@gmail.com> wrote: > 2016-12-14 15:11 GMT-03:00 Volkert <volk...@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 > >
