deployment question
Locked
 
|
Hi,
i have two web-apps based on seaside. Both of them are currently running on an amazon ec2 micro-instance (windows). There are two pharo-instances running, listening on different ports (non-reduced images, gui is running). Both images are behind apache 2.2 (using virtual hosts and mod_proxy). Persistence is image-based, using serialization as seen here: http://onsmalltalk.com/simple-image-based-persistence-in-squeak The number of users is very limited at the time und won't exceed 20 in the next months. The number of domain-objects is very limited too. Is pharo (currently 1.4) the right-choice? Why/ when should i switch to Linux as server? What would be a good argument to migrate to GLASS? regards, Stefan _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: deployment question
|
|
Hi Stefan,
On 04 Apr 2013, at 17:28, Stefan Krecher <[hidden email]> wrote: > Hi, > i have two web-apps based on seaside. Both of them are currently > running on an amazon ec2 micro-instance (windows). > There are two pharo-instances running, listening on different ports > (non-reduced images, gui is running). Both images are behind apache > 2.2 (using virtual hosts and mod_proxy). > Persistence is image-based, using serialization as seen here: > http://onsmalltalk.com/simple-image-based-persistence-in-squeak > The number of users is very limited at the time und won't exceed 20 in > the next months. The number of domain-objects is very limited too. > Is pharo (currently 1.4) the right-choice? > Why/ when should i switch to Linux as server? > What would be a good argument to migrate to GLASS? > regards, > Stefan For a light load (in terms of number of requests per second) you'll be good for a while. Don't optimize unless you need it. For Seaside, step one would be to move all static assets off the image and to apache. The next step is load balancing over a couple of Smalltalk images (with sticky sessions aka session affinity). Larger or multiple ec2 instances comes next. Beware though: ec2 micro instances are CPU throttled, after 1 or 2 minutes of 100% cpu they become extremely slow. In practice this won't matter too much, you just should be aware of it. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On 4 April 2013 18:49, Sven Van Caekenberghe <[hidden email]> wrote:
But then the images would probably have to share data somehow.
Milan Mimica http://sparklet.sf.net _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Stefan Krecher
----- Original Message ----- | From: "Stefan Krecher" <[hidden email]> | To: [hidden email] | Sent: Thursday, April 4, 2013 8:28:21 AM | Subject: [Seaside] deployment question | | Hi, | i have two web-apps based on seaside. Both of them are currently | running on an amazon ec2 micro-instance (windows). | There are two pharo-instances running, listening on different ports | (non-reduced images, gui is running). Both images are behind apache | 2.2 (using virtual hosts and mod_proxy). | Persistence is image-based, using serialization as seen here: | http://onsmalltalk.com/simple-image-based-persistence-in-squeak | The number of users is very limited at the time und won't exceed 20 in | the next months. The number of domain-objects is very limited too. | Is pharo (currently 1.4) the right-choice? | Why/ when should i switch to Linux as server? | What would be a good argument to migrate to GLASS? Stefan, There is no pat answer to this question ... I would recommend that you look ahead and do some load testing (based on anticipated load) on your Pharo1.4-based system in an isolated sandbox (on ec2 or locally), find your bottle necks and try out various solutions ... If you run into a loading issue that you can't easily solve, then ask your question again on this list ... specific problem areas will have specific solutions that may or may not involve having to switch to Linux or GLASS or some other combination. If during load testing you find that the current setup will be able to handle your anticipated needs then you can rest easy:) Dale _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: deployment question
|
|
In reply to this post by mmimica
On 04 Apr 2013, at 18:57, Milan Mimica <[hidden email]> wrote: > On 4 April 2013 18:49, Sven Van Caekenberghe <[hidden email]> wrote: > > The next step is load balancing over a couple of Smalltalk images (with sticky sessions aka session affinity). > > But then the images would probably have to share data somehow. Yes, of course, it all depends on the application. He started with simple image based persistence, it would be overkill to move to GLASS IMHO. If I remember correctly, DabbleDB got away with image based persistence, with an image per user, starting it on demand. > -- > Milan Mimica > http://sparklet.sf.net > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
I have also amazon ec2 micro-instance (windows) running.
I have very good first experiences with MongoTalk, MongoDB and Rockmongo. Glass was overkill for me, too. (I tried it). Greetings Sabine On Thu, Apr 4, 2013 at 8:05 PM, Sven Van Caekenberghe <[hidden email]> wrote: > > On 04 Apr 2013, at 18:57, Milan Mimica <[hidden email]> wrote: > >> On 4 April 2013 18:49, Sven Van Caekenberghe <[hidden email]> wrote: >> >> The next step is load balancing over a couple of Smalltalk images (with sticky sessions aka session affinity). >> >> But then the images would probably have to share data somehow. > > Yes, of course, it all depends on the application. > He started with simple image based persistence, it would be overkill to move to GLASS IMHO. > If I remember correctly, DabbleDB got away with image based persistence, with an image per user, starting it on demand. > >> -- >> Milan Mimica >> http://sparklet.sf.net >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Sven Van Caekenberghe-2
----- Original Message ----- | From: "Sven Van Caekenberghe" <[hidden email]> | To: "Seaside - general discussion" <[hidden email]> | Sent: Thursday, April 4, 2013 11:05:11 AM | Subject: Re: [Seaside] deployment question | | | On 04 Apr 2013, at 18:57, Milan Mimica <[hidden email]> wrote: | | > On 4 April 2013 18:49, Sven Van Caekenberghe <[hidden email]> wrote: | > | > The next step is load balancing over a couple of Smalltalk images (with | > sticky sessions aka session affinity). | > | > But then the images would probably have to share data somehow. | | Yes, of course, it all depends on the application. | He started with simple image based persistence, it would be overkill to move | to GLASS IMHO. | If I remember correctly, DabbleDB got away with image based persistence, with | an image per user, starting it on demand. Sven, DabbleDB got away with "image based persistence", but they invested a fair amount of work in making their version of "image-based persistent" work ... they definitely did not use "simple-image-based persistence" as described by Ramon ... I believe that they leveraged a custom version of image-segments and a few other tricks that were anything but simple... So in the end I don't really think that you can say "DabbleDB got away with image based persistence" ... Dale _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Am 04.04.2013 um 21:43 schrieb Dale Henrichs <[hidden email]>: > > ----- Original Message ----- > | From: "Sven Van Caekenberghe" <[hidden email]> > | To: "Seaside - general discussion" <[hidden email]> > | Sent: Thursday, April 4, 2013 11:05:11 AM > | Subject: Re: [Seaside] deployment question > | > | > | On 04 Apr 2013, at 18:57, Milan Mimica <[hidden email]> wrote: > | > | > On 4 April 2013 18:49, Sven Van Caekenberghe <[hidden email]> wrote: > | > > | > The next step is load balancing over a couple of Smalltalk images (with > | > sticky sessions aka session affinity). > | > > | > But then the images would probably have to share data somehow. > | > | Yes, of course, it all depends on the application. > | He started with simple image based persistence, it would be overkill to move > | to GLASS IMHO. > | If I remember correctly, DabbleDB got away with image based persistence, with > | an image per user, starting it on demand. > > > Sven, > > DabbleDB got away with "image based persistence", but they invested a fair amount of work in making their version of "image-based persistent" work ... they definitely did not use "simple-image-based persistence" as described by Ramon ... I believe that they leveraged a custom version of image-segments and a few other tricks that were anything but simple... > > So in the end I don't really think that you can say "DabbleDB got away with image based persistence" ... > > Dale > Norbert > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
----- Original Message ----- | From: "Norbert Hartl" <[hidden email]> | To: "Seaside - general discussion" <[hidden email]> | Cc: "Seaside - general discussion" <[hidden email]> | Sent: Thursday, April 4, 2013 1:43:17 PM | Subject: Re: [Seaside] deployment question | | > So in the end I don't really think that you can say "DabbleDB got away with | > image based persistence" ... | > | > Dale | > | I think you can. IIRC each customer had his own image. Images are started on | request for a specific customer and shutdown after some time of inactivity. | So that is pretty much what I would call image-based persistency :) | | Norbert Norbert, I wasn't necessarily questioning the image-based persistence part ... I was questioning the "got away with" part, implying that the DabbleDb persistence model was simple.... What happens if there are 10,000 customers and there are 10,000 images and you want to push out a bug fix? DabbleDb addressed this problem. What happens if there are 1,000 customers who want to run at once and all of the images are located on one machine? DabbleDb addressed this problem. What happens if...there are more ... I am sure that you can think of creative ways to solve each of those issues, but my point is the with GLASS you don't have to invent custom solutions to the above problems...GLASS has built-in solutions to those problems ... GLASS also supports the image-based persistence model without requiring modifications to your code ... I am not implying that GLASS is the right solution for everyone it has strengths and drawbacks just like everything else... But to declare that GLASS is overkill and DabbleDb is the poster child for simple, image-based persistence? I think that's ignoring reality a bit:) With all of that said, I go back to my original suggestion ... identify specific performance, scaling problems that you expect to encounter and then start searching for solutions ... the old adage about premature optimization applies ... Dale _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On 04 Apr 2013, at 23:52, Dale Henrichs <[hidden email]> wrote: > I am not implying that GLASS is the right solution for everyone it has strengths and drawbacks just like everything else... > > But to declare that GLASS is overkill and DabbleDb is the poster child for simple, image-based persistence? I think that's ignoring reality a bit:) imho, GLASS offers you the concept of "image-based persistency" with a scalable technology beneath it. Sure, the architecture works differently from what you might be used to in your own Smalltalk environment, but once you learn the ropes (which really should not be a problem for any Smalltalker) it's a walk in the park. cheers Johan_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Dale Henrichs
Am 04.04.2013 um 23:52 schrieb Dale Henrichs <[hidden email]>: > > > ----- Original Message ----- > | From: "Norbert Hartl" <[hidden email]> > | To: "Seaside - general discussion" <[hidden email]> > | Cc: "Seaside - general discussion" <[hidden email]> > | Sent: Thursday, April 4, 2013 1:43:17 PM > | Subject: Re: [Seaside] deployment question > | > | > So in the end I don't really think that you can say "DabbleDB got away with > | > image based persistence" ... > | > > | > Dale > | > > | I think you can. IIRC each customer had his own image. Images are started on > | request for a specific customer and shutdown after some time of inactivity. > | So that is pretty much what I would call image-based persistency :) > | > | Norbert > > Norbert, > > I wasn't necessarily questioning the image-based persistence part ... I was questioning the "got away with" part, implying that the DabbleDb persistence model was simple.... > > What happens if there are 10,000 customers and there are 10,000 images and you want to push out a bug fix? DabbleDb addressed this problem. > > What happens if there are 1,000 customers who want to run at once and all of the images are located on one machine? DabbleDb addressed this problem. > > What happens if...there are more ... > > I am sure that you can think of creative ways to solve each of those issues, but my point is the with GLASS you don't have to invent custom solutions to the above problems...GLASS has built-in solutions to those problems ... GLASS also supports the image-based persistence model without requiring modifications to your code ... > > I am not implying that GLASS is the right solution for everyone it has strengths and drawbacks just like everything else... > > But to declare that GLASS is overkill and DabbleDb is the poster child for simple, image-based persistence? I think that's ignoring reality a bit:) > > With all of that said, I go back to my original suggestion ... identify specific performance, scaling problems that you expect to encounter and then start searching for solutions ... the old adage about premature optimization applies ... Huh! I didn't want to say that you don't need gemstone. I mean I use it quite some time now exactly for that reasons and you know that. I just wanted to make a fun quote because DabbleDB literally did image….based…persistence. That's all! Norbert _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Stefan Krecher
Am 04.04.2013 um 17:28 schrieb Stefan Krecher <[hidden email]>:
As others noted you need to specify your requirements first. You have limited users and a small domain model. How about the request rate? How many read and write requests do you have? Usually the number of concurrent requests is really important. But having a small user base makes that point probably less important. So, solving concurrent requests issues would be a good reason for gemstone. But I doubt this is an actual problem to you. Next is memory. The persistence you use at the moment is memory-bound. That means your model can only be as big as the memory your image has allocated. If your model grows over this you have to change to another persistence mechanism. This would be a very good reason for gemstone. Gemstones heap is not memory limited. Your available space is the size of your memory plus the size of your available disk space. With gemstone your model can grow easily into tens of GBs. Finally the best reason for gemstone would be if you need complex atomic operations or let us call them transactions. That is something that is really unique to gemstone if it comes to persistence. At the moment I don't know any other persistence solution that comes close. Well, yes, SQL databases tend to have transactions as well but you can't do OO stuff in a relational database so they don't count. I don't know of a modern database solution that features transaction. The fashion here is to make about a new buzz word like "eventually consistent" and leave the problem to you. …there is a lot to write about solving problems if the problem isn't clear. So you probably stay with your current solution and solve your business problems until you are starting the face real issues. Then(!) you know the kind of problem you have because you have it. hope this helps, Norbert _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: deployment question
|
|
In reply to this post by Dale Henrichs
On 04 Apr 2013, at 23:52, Dale Henrichs <[hidden email]> wrote: > I am not implying that GLASS is the right solution for everyone it has strengths and drawbacks just like everything else... > > But to declare that GLASS is overkill and DabbleDb is the poster child for simple, image-based persistence? I think that's ignoring reality a bit:) I never used the word 'simple' to describe the DabbleDB system - those were clever guys. What I actually mean is that by being clever in your specific domain you can solve many performance problems. I do however oppose the fact that every question about Smalltalk performance is answered by 'use GLASS and all problems will go away magically and there will be no more limits'. Although I have not (yet) used Gemstone myself, I have heard enough about it to make me careful. 99% of the world solves often huge persistence and scaleability problems using different technologies. GLORP/PostgreSQL is surprisingly fast and scaleable, for example. I am sure one can develop and deploy applications in one and the same, clean, modern, evolving and well maintained Smalltalk, plugging into the tools/stacks that the rest of the world uses. This is just my opinion: there are lots of possibilities, not one. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |