real world pharo web application set ups

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

real world pharo web application set ups

Volkert
After reading reading "Enterprise Pharo a Web perspective", i am curious
to learn more about current real world pharo web application set ups.
any case studies or blue prints around? i am interested in application
domain, system architecture, infrastructure (HW/OS/DB),  performance
goals (concurrent users, transactions, ...), system sizing, scalability
strategies, ....

everything which could important to convince "me" to select pharo as a
platform for a saas solution ...

Thanks,
Volkert


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

NorbertHartl

> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>
> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....
>
> everything which could important to convince "me" to select pharo as a platform for a saas solution …
>
What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?

Norbert




Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Sven Van Caekenberghe-2
Yes, it is a bit too wide a subject ;-)

Anyway, all the cases you find at http://pharo.org/success are successful real-world deployments, but I am sure they are all quite different.

> On 12 Dec 2016, at 19:52, Norbert Hartl <[hidden email]> wrote:
>
>>
>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>
>> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....
>>
>> everything which could important to convince "me" to select pharo as a platform for a saas solution …
>>
> What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?
>
> Norbert


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Joe Shirk
In reply to this post by Volkert
Here is one I am really impressed with; I can't say just how much of it is Pharo:

https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a

On Tue, Dec 13, 2016 at 12:00 PM, <[hidden email]> wrote:
------------------

Message: 1
Date: Mon, 12 Dec 2016 19:16:26 +0100
From: Volkert <[hidden email]>
To: Any question about pharo is welcome <[hidden email]>
Subject: [Pharo-users] real world pharo web application set ups
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

After reading reading "Enterprise Pharo a Web perspective", i am curious
to learn more about current real world pharo web application set ups.
any case studies or blue prints around? i am interested in application
domain, system architecture, infrastructure (HW/OS/DB),  performance
goals (concurrent users, transactions, ...), system sizing, scalability
strategies, ....

everything which could important to convince "me" to select pharo as a
platform for a saas solution ...

Thanks,
Volkert




Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Volkert
In reply to this post by NorbertHartl


On 12.12.2016 19:52, Norbert Hartl wrote:

>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>
>> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....
>>
>> everything which could important to convince "me" to select pharo as a platform for a saas solution …
>>
> What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?
>
> Norbert
>
>
I like to know more about current real world pharo web application set up ... not more, not less.

Think of a environmental information management system
50000 User / 500 Concurrent
Data Aggregation
Data Refinement / Processing
Data Visualization
15-20 Dataprovider
Web UI




Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Volkert
In reply to this post by Sven Van Caekenberghe-2


On 12.12.2016 20:05, Sven Van Caekenberghe wrote:
> Yes, it is a bit too wide a subject ;-)
>
> Anyway, all the cases you find at http://pharo.org/success are successful real-world deployments, but I am sure they are all quite different.
i looked already, but there is a problem with the page. all
screenshots/pictures have a wrong scaling ...

>> On 12 Dec 2016, at 19:52, Norbert Hartl <[hidden email]> wrote:
>>
>>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>>
>>> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....
>>>
>>> everything which could important to convince "me" to select pharo as a platform for a saas solution …
>>>
>> What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?
>>
>> Norbert
>


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Sven Van Caekenberghe-2
In reply to this post by Joe Shirk

> On 13 Dec 2016, at 19:48, Joe Shirk <[hidden email]> wrote:
>
> Here is one I am really impressed with; I can't say just how much of it is Pharo:
>
> https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a

Well, not all of it is Pharo, far from it, but currently we have about 20 Pharo images running in production, doing various jobs ranging from web apps to various back end application server tasks under real world load.

Sven

> On Tue, Dec 13, 2016 at 12:00 PM, <[hidden email]> wrote:
> ------------------
>
> Message: 1
> Date: Mon, 12 Dec 2016 19:16:26 +0100
> From: Volkert <[hidden email]>
> To: Any question about pharo is welcome <[hidden email]>
> Subject: [Pharo-users] real world pharo web application set ups
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> After reading reading "Enterprise Pharo a Web perspective", i am curious
> to learn more about current real world pharo web application set ups.
> any case studies or blue prints around? i am interested in application
> domain, system architecture, infrastructure (HW/OS/DB),  performance
> goals (concurrent users, transactions, ...), system sizing, scalability
> strategies, ....
>
> everything which could important to convince "me" to select pharo as a
> platform for a saas solution ...
>
> Thanks,
> Volkert
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

jtuchel
In reply to this post by Volkert
Volkert,

I surely cannot help you with concrete answers. We are not even using
Pharo for our Seaside App.

All I've learned is that all of these questions are extremely hard to
answer. Will Pharo or any other Server side technology scale? Forget it,
nobody will be able to tell you the truth.

What I've learnt so far is that this whole thing is mostly a question of
distributing services between servers (images and external processes).
Make things small and devidable. Load the number crunching off of your
web facing image and build clever UIs that give good feedback about the
progress of lengthy operations.

If I tell you that my current estimate is that a Smalltalk image with
Seaside will not be able to handle more than 20 concurrent users, in
many cases even less. What does that actually tell you? YMMV based on
the work that is done in that image, and there are so many influencing
factors. If of these 20 users only 1 currently asks for heavy
computation, this can already mean the server is slow for the other 19.

Our Application is very different from what you describe: Accounting is
mostly CRUD operations, which means there are not many things you can
delegate to external programs or even servers. Your scenario sounds very
different. It sounds like you can do the data aggregation and refinement
part in a separate (maybe REST based and stateless) server and mostly
render nice "wait, we're working for you" dialogs and present nice
results once they're done. This scales wonderfully and the front-end web
server mostly does nothing other than send out self-reloading
please-wait pages. Such a server (image) can probably even handle 50 or
more concurrent users. Thus you end up with several layers on which you
can scale easily and mostly independently. If your aggreations are slow,
add a few images that do the aggregations.

So if your question is whether you can handle 500 concurrent users in
Smalltalk or Pharo with Seaside, the answer is definitely YES. If you
want to know how many Images are needed, how many servers you'd have to
order, you'll probably not get any useful answers. My feeling is that
you can't know exactly because every app is so different. There probably
are just not enough projects out there to collect relevant data...

Joachim



Am 13.12.16 um 20:06 schrieb Volkert:

>
>
> On 12.12.2016 19:52, Norbert Hartl wrote:
>>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>>
>>> After reading reading "Enterprise Pharo a Web perspective", i am
>>> curious to learn more about current real world pharo web application
>>> set ups. any case studies or blue prints around? i am interested in
>>> application domain, system architecture, infrastructure (HW/OS/DB),  
>>> performance goals (concurrent users, transactions, ...), system
>>> sizing, scalability strategies, ....
>>>
>>> everything which could important to convince "me" to select pharo as
>>> a platform for a saas solution …
>>>
>> What you really want to know? All the things you mentioned above are
>> not pharo related at all! Can you at least roughly sketch in which
>> area you would consider to use pharo?
>>
>> Norbert
>>
>>
> I like to know more about current real world pharo web application set
> up ... not more, not less.
>
> Think of a environmental information management system
> 50000 User / 500 Concurrent
> Data Aggregation
> Data Refinement / Processing
> Data Visualization
> 15-20 Dataprovider
> Web UI
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Sven Van Caekenberghe-2
In reply to this post by Volkert

> On 13 Dec 2016, at 20:07, Volkert <[hidden email]> wrote:
>
>
>
> On 12.12.2016 20:05, Sven Van Caekenberghe wrote:
>> Yes, it is a bit too wide a subject ;-)
>>
>> Anyway, all the cases you find at http://pharo.org/success are successful real-world deployments, but I am sure they are all quite different.
> i looked already, but there is a problem with the page. all screenshots/pictures have a wrong scaling ...

Hmm, they look fine on Safari and Google Chrome, but they seem off in Firefox - weird.

>>> On 12 Dec 2016, at 19:52, Norbert Hartl <[hidden email]> wrote:
>>>
>>>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>>>
>>>> After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....
>>>>
>>>> everything which could important to convince "me" to select pharo as a platform for a saas solution …
>>>>
>>> What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?
>>>
>>> Norbert
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Volkert
In reply to this post by jtuchel
Thanks Joachim, for the answer. I had the same thoughts about the
architecture. And yes of course, there
is no easy and simple answer ... such an answer is always wrong ... So
it is more important to see, were for which parts of distributed
architectures 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 - ...

i will now read the BetaNine case, Joe mentioned ;-)

On 13.12.2016 20:29, [hidden email] wrote:

> Volkert,
>
> I surely cannot help you with concrete answers. We are not even using
> Pharo for our Seaside App.
>
> All I've learned is that all of these questions are extremely hard to
> answer. Will Pharo or any other Server side technology scale? Forget
> it, nobody will be able to tell you the truth.
>
> What I've learnt so far is that this whole thing is mostly a question
> of distributing services between servers (images and external
> processes). Make things small and devidable. Load the number crunching
> off of your web facing image and build clever UIs that give good
> feedback about the progress of lengthy operations.
>
> If I tell you that my current estimate is that a Smalltalk image with
> Seaside will not be able to handle more than 20 concurrent users, in
> many cases even less. What does that actually tell you? YMMV based on
> the work that is done in that image, and there are so many influencing
> factors. If of these 20 users only 1 currently asks for heavy
> computation, this can already mean the server is slow for the other 19.
>
> Our Application is very different from what you describe: Accounting
> is mostly CRUD operations, which means there are not many things you
> can delegate to external programs or even servers. Your scenario
> sounds very different. It sounds like you can do the data aggregation
> and refinement part in a separate (maybe REST based and stateless)
> server and mostly render nice "wait, we're working for you" dialogs
> and present nice results once they're done. This scales wonderfully
> and the front-end web server mostly does nothing other than send out
> self-reloading please-wait pages. Such a server (image) can probably
> even handle 50 or more concurrent users. Thus you end up with several
> layers on which you can scale easily and mostly independently. If your
> aggreations are slow, add a few images that do the aggregations.
>
> So if your question is whether you can handle 500 concurrent users in
> Smalltalk or Pharo with Seaside, the answer is definitely YES. If you
> want to know how many Images are needed, how many servers you'd have
> to order, you'll probably not get any useful answers. My feeling is
> that you can't know exactly because every app is so different. There
> probably are just not enough projects out there to collect relevant
> data...
>
> Joachim
>
>
>
> Am 13.12.16 um 20:06 schrieb Volkert:
>>
>>
>> On 12.12.2016 19:52, Norbert Hartl wrote:
>>>> Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:
>>>>
>>>> After reading reading "Enterprise Pharo a Web perspective", i am
>>>> curious to learn more about current real world pharo web
>>>> application set ups. any case studies or blue prints around? i am
>>>> interested in application domain, system architecture,
>>>> infrastructure (HW/OS/DB),  performance goals (concurrent users,
>>>> transactions, ...), system sizing, scalability strategies, ....
>>>>
>>>> everything which could important to convince "me" to select pharo
>>>> as a platform for a saas solution …
>>>>
>>> What you really want to know? All the things you mentioned above are
>>> not pharo related at all! Can you at least roughly sketch in which
>>> area you would consider to use pharo?
>>>
>>> Norbert
>>>
>>>
>> I like to know more about current real world pharo web application
>> set up ... not more, not less.
>>
>> Think of a environmental information management system
>> 50000 User / 500 Concurrent
>> Data Aggregation
>> Data Refinement / Processing
>> Data Visualization
>> 15-20 Dataprovider
>> Web UI
>>
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Vitor Medina Cruz
In reply to this post by jtuchel
If I tell you that my current estimate is that a Smalltalk image with Seaside will not be able to handle more than 20 concurrent users, in many cases even less. 

Seriously? That is kinda a low number, I would expect more for each image. Certainly it depends much on many things, but it is certainly very low for a rough estimate, why you say that?

On Tue, Dec 13, 2016 at 5:29 PM, [hidden email] <[hidden email]> wrote:
Volkert,

I surely cannot help you with concrete answers. We are not even using Pharo for our Seaside App.

All I've learned is that all of these questions are extremely hard to answer. Will Pharo or any other Server side technology scale? Forget it, nobody will be able to tell you the truth.

What I've learnt so far is that this whole thing is mostly a question of distributing services between servers (images and external processes). Make things small and devidable. Load the number crunching off of your web facing image and build clever UIs that give good feedback about the progress of lengthy operations.

If I tell you that my current estimate is that a Smalltalk image with Seaside will not be able to handle more than 20 concurrent users, in many cases even less. What does that actually tell you? YMMV based on the work that is done in that image, and there are so many influencing factors. If of these 20 users only 1 currently asks for heavy computation, this can already mean the server is slow for the other 19.

Our Application is very different from what you describe: Accounting is mostly CRUD operations, which means there are not many things you can delegate to external programs or even servers. Your scenario sounds very different. It sounds like you can do the data aggregation and refinement part in a separate (maybe REST based and stateless) server and mostly render nice "wait, we're working for you" dialogs and present nice results once they're done. This scales wonderfully and the front-end web server mostly does nothing other than send out self-reloading please-wait pages. Such a server (image) can probably even handle 50 or more concurrent users. Thus you end up with several layers on which you can scale easily and mostly independently. If your aggreations are slow, add a few images that do the aggregations.

So if your question is whether you can handle 500 concurrent users in Smalltalk or Pharo with Seaside, the answer is definitely YES. If you want to know how many Images are needed, how many servers you'd have to order, you'll probably not get any useful answers. My feeling is that you can't know exactly because every app is so different. There probably are just not enough projects out there to collect relevant data...

Joachim



Am 13.12.16 um 20:06 schrieb Volkert:



On 12.12.2016 19:52, Norbert Hartl wrote:
Am 12.12.2016 um 19:16 schrieb Volkert <[hidden email]>:

After reading reading "Enterprise Pharo a Web perspective", i am curious to learn more about current real world pharo web application set ups. any case studies or blue prints around? i am interested in application domain, system architecture, infrastructure (HW/OS/DB),  performance goals (concurrent users, transactions, ...), system sizing, scalability strategies, ....

everything which could important to convince "me" to select pharo as a platform for a saas solution …

What you really want to know? All the things you mentioned above are not pharo related at all! Can you at least roughly sketch in which area you would consider to use pharo?

Norbert


I like to know more about current real world pharo web application set up ... not more, not less.

Think of a environmental information management system
50000 User / 500 Concurrent
Data Aggregation
Data Refinement / Processing
Data Visualization
15-20 Dataprovider
Web UI








Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Esteban A. Maringolo
In reply to this post by Volkert
2016-12-14 15:11 GMT-03:00 Volkert <[hidden email]>:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

kilon.alios
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 <[hidden email]> wrote:
2016-12-14 15:11 GMT-03:00 Volkert <[hidden email]>:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Esteban A. Maringolo
2016-12-14 15:41 GMT-03:00 Dimitris Chloupis <[hidden email]>:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

kilon.alios
"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."

There is parallelism which means code that execute at the same time instruction by instruction  
There is concurency which means code that executes a bit of it from different parts giving the illusion that codes run at the same time

OS threads do parallelism
VM threads , aka green threads, do concurrency

VM technically speaking uses several OS threads but the byte code is indeed executed on the main thread only , thus VM alllows only green threads for pharo code. 

I am not saying you do not know this stuff, I am just mention it here so everyone is on the same page. 

You cannot have more parallelism than cores, actually that may not be true because I think each core allows for two parallel threads because of hyperthreading but more or less thats the idea. 

Just for the record there are cases when multiple OS threads running on multiple cores can be actually slower than one thread running on one core. This the nightmare that is called parallelism and why coders generally avoid it.  The usually reason why multiple OS threads may be slower it has to do with CPU cache and how it exchanges data between threads and CPU cores. 

I had the pleasure of getting a taste of this nightmare when I was learning OpenMP which is the most popular library for parallel execution for C/C++. Of course there are also the usual problems with synchronisation etc. 

Technically speaking you can do OS threads from Pharo with my CPP library. Thats possible because CPP works by having two isolated process (actually you can have an infinite amount of processes if your hardware can handle them ) , in this case one C++ executable and one for Pharo that share an area of memory that both can directly access to. You could implement callbacks to, you could do anything and you would not have to worry about joining threads or providing compatibility with Pharo VM because you deal with shared data and not code execution.  Because CPP uses shared memory which in turn uses OS kernel native memory access and management functions, you get top speed. 

So you can have one process using OpenMP taking full advantage of the hardware acceleration (triggering multiple OS threads) of your CPU cores and one for Pharo that will drive the OpenMP process. 

There is still the issue of data synchronisation, who locks the data and who accesses it at what time, but those are usual issues for any kind of thread orientated coding, you wont be doing anything diffirent. 

"However any CPU intensive request will block the process, and that
will happen with looping server like Pharo or an evented VM like
NodeJS."

Again you can avoid that with my CPP library. You do not need to block , you could let the external process do its thing and just block it when you decide to fetch data after it finishes or on specific intervals. There are so many ways you can do this. You can also have like the VM one central OS thread that is able to be blocked by Pharo and multiple secondary ones that Pharo will have no control over either than the level of control that the main thread provides. 

In any case, most servers run Apache which should deal with many of those issues, there are wrappers for many languages , Apaches is wrriten in C/C++ so its should be able to tap into this technology to avoid solving problems that have been already solved. So its a matter of writing wrappers for Pharo too.

On Wed, Dec 14, 2016 at 8:59 PM Esteban A. Maringolo <[hidden email]> wrote:
2016-12-14 15:41 GMT-03:00 Dimitris Chloupis <[hidden email]>:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Ramon Leon-5
In reply to this post by Esteban A. Maringolo
On 12/14/2016 10:27 AM, Esteban A. Maringolo wrote:
> 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.

Sure you can, a multi-core server isn't going to get maxed out by idle
CPU consumption as each image will only do that on a single core; you
can also reduce consumption on headless images by suspending the UI
process which isn't needed getting you down to perhaps 2-3%.

> whilst 10 idle Pharo images will consume 50%.

Only on a single CPU machine which isn't what you're going to have on a
server. Running two images per core on a 12 core virtual server and
you'll be sitting more like 5-6% idle which is totally fine. Spread that
across 10 or 15 virtual servers and you can handle 1000 concurrent users
just fine.

--
Ramon Leon


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Stephan Eggermont-3
In reply to this post by kilon.alios
On 14/12/16 19:41, Dimitris Chloupis wrote:
> 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.

You can probably run a few thousand images on a single high-end x86
server (2*22 Core Xeon, 1TB ram). I just started 21 images on my
dual-core i5 MBP. top tells me my system is 75-80% idle, pharo processes
taking 2-3%CPU and 1.6GB MEM (33MB-146MB)

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Esteban A. Maringolo
In reply to this post by Ramon Leon-5
2016-12-14 16:31 GMT-03:00 Ramon Leon <[hidden email]>:

> On 12/14/2016 10:27 AM, Esteban A. Maringolo wrote:
>>
>> 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.
>
>
> Sure you can, a multi-core server isn't going to get maxed out by idle CPU
> consumption as each image will only do that on a single core; you can also
> reduce consumption on headless images by suspending the UI process which
> isn't needed getting you down to perhaps 2-3%.

Can you extend on suspending the UI process? I never did that.

>> whilst 10 idle Pharo images will consume 50%.

> Only on a single CPU machine which isn't what you're going to have on a
> server. Running two images per core on a 12 core virtual server and you'll
> be sitting more like 5-6% idle which is totally fine. Spread that across 10
> or 15 virtual servers and you can handle 1000 concurrent users just fine.

Won't the idle use add up?

In my case I served up to 20 concurrent users (out of ~100 total) with
only 5 images. Plus another two images for the REST API. In a dual
core server.

Regards.

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Ramon Leon-5
On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote:
> Can you extend on suspending the UI process? I never did that.

I feed my images a start script on the command line

pharo-vm-nox \
     -vm-sound-null -vm-display-null \
     /var/pharo/app.image \
     /var/pharo/startScript

startScript containing one line (among others) like so...

        Project uiProcess suspend.

I'm on an older Pharo, but I presume the newer ones are the same or
similar. No sense in wasting CPU on a UI in a headless image

> Won't the idle use add up?

Sure eventually, but you don't run more than a 2 or so per core so
that'll never be a problem.  You shouldn't be running 5 images on a
single core, let alone more.

> In my case I served up to 20 concurrent users (out of ~100 total) with
> only 5 images. Plus another two images for the REST API. In a dual
> core server.

That's barely a server, most laptops these days have more cores. Rent a
virtual server with a dozen or more cores, then you can run a few images
per core without the idle mattering at all and run 2 dozen images in
total per 12 core server.

Scale by adding cores and ram allowing you to run more images per box;
or scale by running more boxes, ultimately, you need to spread out the
load across many many cores.

--
Ramon Leon


Reply | Threaded
Open this post in threaded view
|

Re: real world pharo web application set ups

Vitor Medina Cruz
Pharo don't have non-blocking I/O?

On Wed, Dec 14, 2016 at 6:59 PM, Ramon Leon <[hidden email]> wrote:
On 12/14/2016 12:09 PM, Esteban A. Maringolo wrote:
Can you extend on suspending the UI process? I never did that.

I feed my images a start script on the command line

pharo-vm-nox \
    -vm-sound-null -vm-display-null \
    /var/pharo/app.image \
    /var/pharo/startScript

startScript containing one line (among others) like so...

        Project uiProcess suspend.

I'm on an older Pharo, but I presume the newer ones are the same or similar. No sense in wasting CPU on a UI in a headless image

Won't the idle use add up?

Sure eventually, but you don't run more than a 2 or so per core so that'll never be a problem.  You shouldn't be running 5 images on a single core, let alone more.

In my case I served up to 20 concurrent users (out of ~100 total) with
only 5 images. Plus another two images for the REST API. In a dual
core server.

That's barely a server, most laptops these days have more cores. Rent a virtual server with a dozen or more cores, then you can run a few images per core without the idle mattering at all and run 2 dozen images in total per 12 core server.

Scale by adding cores and ram allowing you to run more images per box; or scale by running more boxes, ultimately, you need to spread out the load across many many cores.

--
Ramon Leon



12