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