[Seaside] Re: Seaside memory consumption?
m.coba.m at gmail.com
Wed Apr 30 00:11:16 UTC 2008
On Tue, Apr 29, 2008 at 6:55 PM, Miguel Cobá <m.coba.m at gmail.com> wrote:
> On Tue, Apr 29, 2008 at 2:40 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> > 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)
> I had my app running from a VPS with just 256MB RAM. Of course after the
> OS, apache, mysql, it lefted just 100MB or so. It was just imposible to
> work. So I upgraded to 512MB RAM and all was running ok for days without
> problems with my app.
> The image virtual memory grew and grew until took the entire remaining RAM
> to the point that I couldn't login with ssh. Not memory for forking a ssh
> procces was left. I had to restart the server to take control of it (the
> image didn't started automatically). I found an option for the squeakvm to
> limit the max memory available (it is not available because if the images
> need more memory it will begin to swap
I meant: (it is not advisable because if the image need more memory ...
> and will be slow, but men, it worked).
> After reboot, I was left with 350 MB free before running my image. So I
> started the image with
> squeakvm -mmap 300m -headless deploy.image
> so the squeak used at most 300 mb and the os had 50 MB for ssh logins.
> Also, I changed Apache for lighttpd with fastcgi so to reduce the RAM
> Miguel Cobá
> > 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.
> > 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?
> > Cheers,
> > - Andreas
> > _______________________________________________
> > seaside mailing list
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside