Seaside memory consumption?

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)

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Tue, Apr 29, 2008 at 2:40 PM, Andreas Raab <[hidden email]> 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.

but...

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

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

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Miguel,

 

    you always have and share interesting experiences. I like to use Monit not only because you can set it to starts workers images but also you can set it to provide you of more details on the run. For instance you can set it send you an email alert when a worker mem is > 150MB or the CPU load average is >25% for more than 5 minutes. And, beside the cool email alert, you can preset reactions like restarting the worker, etc.

 

    That way your service dont need to reach perfection to be useful and when things go wrong with a worker it most probably restart in few minutes unnatended. I'm very satisfied with it. Also Munin is cool but it is for a different purpose, it plots lots of metrics evolutions in time of your servers so you can watch more general performance patterns.

 

    There are perfect setup how-tos for those interested,

  

   cheers,

 

Sebastian Sastre

---

De: [hidden email] [mailto:[hidden email]] En nombre de Miguel Cobá
Enviado el: Martes, 29 de Abril de 2008 20:55
Para: Seaside - general discussion
Asunto: Re: [Seaside] Re: Seaside memory consumption?

On Tue, Apr 29, 2008 at 2:40 PM, Andreas Raab <[hidden email]> 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.

but...

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

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