deployment question

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

deployment question

Stefan Krecher
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Sven Van Caekenberghe-2
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

mmimica
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.


--
Milan Mimica
http://sparklet.sf.net

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Dale Henrichs
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Sven Van Caekenberghe-2
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Sabine Manaa
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Dale Henrichs
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

NorbertHartl


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
>
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
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Dale Henrichs


----- 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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Johan Brichau-2

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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

NorbertHartl
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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

NorbertHartl
In reply to this post by Stefan Krecher

Am 04.04.2013 um 17:28 schrieb Stefan Krecher <[hidden email]>:

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?

When you feel comfortable doing it. In my(!) opinion Linux is much better suited for building a reliable server than windows is. But then I don't have a big knowledge about windows. If you are using windows and you know how to deal problems with it and Linux is something new then it might not be a good idea to switch. Working in smalltalk mostly means to abstract the underlying OS and work in the smalltalk environment. That means that the operating system isn't important as long as it runs reliable.

What would be a good argument to migrate to GLASS?

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.
 
So if none of the problems above seems to be one of yours gemstone is not (yet) the best choice for you. I would examine the model once more and look for partition borders. That means determine regions in your model that are self-contained. These regions can be swapped out of memory if not being used. You could use Fuel to swap out a such a sub object graph to disc and read it back when you need it. This depends on the rate of write requests to your model. If the rate isn't very high Fuel might work because it is itself quite fast. This would extend the memory case in some way.

…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
Reply | Threaded
Open this post in threaded view
|

Re: deployment question

Sven Van Caekenberghe-2
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