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, jtuc...@objektfabrik.de 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 <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
