Hi -
I'm contemplating to use Seaside and Magritte to mock up an administrative interface for internal use but for various reasons this may have to run inside an image that does actual production work. Because the work can at times be memory intensive, I'm interested in learning more about memory consumption of Seaside and Magritte. Are there any guidelines for "reasonable" working sets of memory for Seaside (depending on load)? What about memory consumption of Seaside apps that run for several months without restart (session cleanup etc)?
Thanks for any insights, - Andreas
Hi Andreas,
in a case like that I most probably will consider a more decoupled so flexible architecture: seaside app in worker image/s, remote access to the inspected images.
All can be restarted without affecting each other (too much), they can be in different hosts workers when fail wont affect observed image (guaranteed), etc.
cheers,
Sebastian Sastre
-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Andreas Raab Enviado el: Lunes, 28 de Abril de 2008 21:22 Para: The Squeak Enterprise Aubergines Server - general discussion. Asunto: [Seaside] Seaside memory consumption?
Hi -
I'm contemplating to use Seaside and Magritte to mock up an administrative interface for internal use but for various reasons this may have to run inside an image that does actual production work. Because the work can at times be memory intensive, I'm interested in learning more about memory consumption of Seaside and Magritte. Are there any guidelines for "reasonable" working sets of memory for Seaside (depending on load)? What about memory consumption of Seaside apps that run for several months without restart (session cleanup etc)?
Thanks for any insights,
- Andreas
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Sebastian Sastre wrote:
in a case like that I most probably will consider a more decoupled so flexible architecture: seaside app in worker image/s, remote access to the inspected images.
Yes, that's one of the possible alternatives. Unfortunately, it would require serious additional work, which I'd really like to avoid initially by just running the interface out of the image in question. This still leaves me with the same question: Any experience with Seaside memory consumption anyone?
Cheers, - Andreas
All can be restarted without affecting each other (too much), they can be in different hosts workers when fail wont affect observed image (guaranteed), etc.
cheers,
Sebastian Sastre
-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Andreas Raab Enviado el: Lunes, 28 de Abril de 2008 21:22 Para: The Squeak Enterprise Aubergines Server - general discussion. Asunto: [Seaside] Seaside memory consumption?
Hi -
I'm contemplating to use Seaside and Magritte to mock up an administrative interface for internal use but for various reasons this may have to run inside an image that does actual production work. Because the work can at times be memory intensive, I'm interested in learning more about memory consumption of Seaside and Magritte. Are there any guidelines for "reasonable" working sets of memory for Seaside (depending on load)? What about memory consumption of Seaside apps that run for several months without restart (session cleanup etc)?
Thanks for any insights,
- Andreas
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Ok. Then I let you know, just in case and/or for the future, I'm doing that with rST and that lower that costs considerably.
cheers,
Sebastian
-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Andreas Raab Enviado el: Martes, 29 de Abril de 2008 12:54 Para: Seaside - general discussion Asunto: [Seaside] Re: Seaside memory consumption?
Sebastian Sastre wrote:
in a case like that I most probably will consider a
more decoupled so
flexible architecture: seaside app in worker image/s,
remote access to the
inspected images.
Yes, that's one of the possible alternatives. Unfortunately, it would require serious additional work, which I'd really like to avoid initially by just running the interface out of the image in question. This still leaves me with the same question: Any experience with Seaside memory consumption anyone?
Cheers,
- Andreas
All can be restarted without affecting each other (too
much), they can
be in different hosts workers when fail wont affect
observed image (guaranteed),
etc.
cheers,
Sebastian Sastre
-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Andreas Raab Enviado el: Lunes, 28 de Abril de 2008 21:22 Para: The Squeak Enterprise Aubergines Server - general discussion. Asunto: [Seaside] Seaside memory consumption?
Hi -
I'm contemplating to use Seaside and Magritte to mock up an administrative interface for internal use but for various reasons this may have to run inside an image that does actual production work. Because the work can at times be memory intensive, I'm
interested in
learning more about memory consumption of Seaside and
Magritte. Are
there any guidelines for "reasonable" working sets of memory for Seaside (depending on load)? What about memory consumption of Seaside apps that run for several months without restart (session cleanup etc)?
Thanks for any insights,
- Andreas
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2008/4/29 Andreas Raab andreas.raab@gmx.de:
Hi -
I'm contemplating to use Seaside and Magritte to mock up an administrative interface for internal use but for various reasons this may have to run inside an image that does actual production work. Because the work can at times be memory intensive, I'm interested in learning more about memory consumption of Seaside and Magritte. Are there any guidelines for "reasonable" working sets of memory for Seaside (depending on load)?
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.
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.
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.
Cheers Philippe
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
2008/4/29 Andreas Raab andreas.raab@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 image.
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?
http://bugs.squeak.org/view.php?id=6348 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 production.
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
Cheers Philippe
2008/4/29 Philippe Marschall philippe.marschall@gmail.com:
2008/4/29 Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
As it turned out there was a lot of crap in my mail.
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 image.
The Seaside homepage like all other images has -mmap 256 mb
.....
http://bugs.squeak.org/view.php?id=6348 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 production.
With this patch you can chance SeasidePlatformSupport >> #weakDictionaryOfSize: to:
weakDictionaryOfSize: aNumber | dict | dict := WeakIdentityKeyDictionary new: aNumber. WeakArray addWeakDependent: dict. ^ dict
This is useless in Seaside 2.8, simply ignore it.
Cheers Philippe
On Tue, Apr 29, 2008 at 2:40 PM, Andreas Raab andreas.raab@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.
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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Tue, Apr 29, 2008 at 6:55 PM, Miguel Cobá m.coba.m@gmail.com wrote:
On Tue, Apr 29, 2008 at 2:40 PM, Andreas Raab andreas.raab@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.
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
I meant: (it is not advisable because if the image need more memory ...
Miguel Cobá
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 seaside@lists.squeakfoundation.org 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: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] 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 andreas.raab@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.
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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
I have intended to use Monit, as I saw in a Ramon Leon's post. But I have never play with it. I didn't know Munin, it is interesting. Thanks for the tip.
Miguel Cobá
On Tue, Apr 29, 2008 at 10:01 PM, Sebastian Sastre ssastre@seaswork.com wrote:
Hi Miguel,
you always have and share interesting experiences. I like to use Monitnot 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 andwhen 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:* seaside-bounces@lists.squeakfoundation.org [mailto: seaside-bounces@lists.squeakfoundation.org] *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 andreas.raab@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.
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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi,
FWIW, see http://lists.squeakfoundation.org/pipermail/seaside/2008-February/016558.htm...
It's about Lukas' personal site. (so based on Pier). I guess there is more than 128MB though. I have 1GB and so no problem for three monthes (only one time image stuck at 99%, but that's all).
Cédrick
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)
"cdrick" cdrick65@gmail.com wrote
It's about Lukas' personal site. (so based on Pier). I guess there is more than 128MB though. I have 1GB and so no problem for three monthes (only one time image stuck at 99%, but that's all).
How does one set this value (on Windows), and what does it default to (on Windows)?
- Sophie
seaside@lists.squeakfoundation.org
-
Andreas Raab -
cdrick -
itsme213 -
Miguel Cobá -
Philippe Marschall -
Sebastian Sastre