[Seaside] deployment question

Norbert Hartl norbert at hartl.name
Fri Apr 5 08:50:17 UTC 2013

Am 04.04.2013 um 17:28 schrieb Stefan Krecher <stefan.krecher at googlemail.com>:

> 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,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20130405/27c37804/attachment.htm

More information about the seaside mailing list