[Seaside] Re: Seaside memory consumption?

Philippe Marschall philippe.marschall at gmail.com
Tue Apr 29 20:12:41 UTC 2008

2008/4/29 Andreas Raab <andreas.raab at gmx.de>:
> Philippe Marschall wrote:
> > Honestly this is a very hard question that probably only marketing
> > developments can answer seriously (JEE is twice as fast as .Net). If
> > have seen such numbers for no web framework. There are so many free
> > variables. How have active users, what session lifetime, how active
> > are they, do they come in bursts, how complicated is your site, what
> > image do you have, which VM, which GC settings, which patches, which
> > OS, which CPU, .... . Out of the blue I would say Seaside and Magritte
> > are probably the most memory hungry choices you can make. Lots of
> > classes, lots of objects, lots of block contexts, .... Having that
> > said I know of no one who has run into memory problems with Seaside /
> > Magritte but this means very little. In general persistence is often
> > bottleneck. As you run code besides it I doubt any numbers would be
> > applicable to you.
> >
>  I fully understand the number of variables in the setup so what I'm looking
> for is whether anyone has experimented with -say- running Seaside inside a
> 128MB environment for a given site and load factor and what their
> experiences were. For example, what does a small Pier deployment require?
> (IIRC, it is built on top of Magritte so this may be the closest in kind)

128 MB is IMHO the absolute minimum with a standard Squeak image.
SeasideHosting for example gives each application 256 MB. The Seaside
homepage runs on SeasideHosting too but has all quotas off. You might
want to ask Lukas for the exact numbers. On an average day we get
between 200 and 400 visitors with more than 1500 on special occasions.
However the Seaside homepage is mostly read only and simply saves the

> > In general people who come up with such questions have an idea about
> > the load they'll face or have to support so they can write tests.
> >
>  Yes, I certainly do (it'd be in the range of 1-2 man-hours of use a day,
> basically filling in a bunch of forms and running a few reports mostly by a
> single user). But I'm not going to run a big test suite for something that
> is supposed to be a very small application. I just want to make sure I'm not
> going to screw up the production app by running Seaside next to it.

If your looking for tools to do this you might want to give Albatross
[1] or Seaside Testing [2] a try. There are a ton of other tools but
Seaside is not so testing friendly because it wants to take care of
URLs and form field names.

> >
> > > What
> > > about memory consumption of Seaside apps that run for several months
> without
> > > restart (session cleanup etc)?
> > >
> >
> > Session cleanup happens even without restarts. If you run the
> > WeakDictionary patches of Martin van Löws (I hope I got the name
> > right) you can override SeasidePlatformSupport class >>
> > #weakDictionaryOfSize: which should release sessions earlier. I have
> > seen images that run without troubles for months and images that have
> > trouble staying up for more than a few days.
> >
>  Thanks, that's good to know, too. Where are these patches?

I somehow got the impression that you had these patches applied to
your images. If that is not the case then I don't suggest you apply
them simply because I have heard of no one who uses them in

With this patch you can chance SeasidePlatformSupport >>
#weakDictionaryOfSize: to:

weakDictionaryOfSize: aNumber
	| dict |
	dict := WeakIdentityKeyDictionary new: aNumber.
	WeakArray addWeakDependent: dict.
	^ dict

[1] http://www.squeaksource.com/Albatross.html
[2] http://www.squeaksource.com/SeasideTesting.html


More information about the seaside mailing list