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 <volk...@nivoba.de>:
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
