On Aug 27, 4:47 pm, Paul Rauch <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kenneth Gonsalves schrieb:> Hi, > > > I have a site on WebFaction with 40 MB RAM. It is a very small site > > in the sense that it is used for administering an organisation, so > > would have just 2-3 users at a time, mainly doing admin stuff. The > > only load is when pdf reports are being generated. Leaving apache > > untweaked, the RAM usage shoots up - well over the 40 MB limit. I set > > MaxRequestsPerChild to 3. Even then, the limit gets crossed pretty > > fast. The question is: do I go on trying to tweak Apache? Or do I go > > in for more RAM? > > you might want to try another webserver, > maybe lighttpd and then run django as fastcgi. > at least its said to be more performant. > > http://www.djangoproject.com/documentation/fastcgi/
In terms of memory consumed, in practice using fastcgi wouldn't make that much difference. This is because by far the bulk of memory used is by the Django application itself. If the increase in memory is due principally to the PDF generation, and the incidence of PDF generation is low, they would be better off factoring out the PDF generation into a separate script if they can, which is then executed from the Django application using os.system or the popen modules. This will match better with how WebFaction calculates memory usage, as they only have a problem with long running processes over the 40MB limit if I remember correctly. By factoring it out into a script, the memory consuming process is then ephemeral and memory only gets consumed for a short time. As a result, it wouldn't matter if for that short time it goes over 40MB in size. Obviously if the one script is consuming absolute huge amounts of memory, then they may have an issue. The only other solution which may work within the bounds of WebFaction's memory limits is to use mod_wsgi with Apache instead of mod_python. If you have a 4 process limit on long running processes, ensure you are using 'worker' MPM in Apache and limit the number of Apache child processes to 2. Then use mod_wsgi daemon mode to have one daemon process with many threads which runs your Django instance. Also create a second daemon process with mod_wsgi and delegate only the subset of URLs from your Django application which generate the PDFs to this second daemon process. In other words, one daemon process is used to run all parts of the application except for the URLs which do the PDF generation. These URLs are instead delegated to run in a distinct daemon process. Because the PDF daemon process isn't handling all URLs for the application, it will not accumulate any cached modules and data related to the URLs not being handled, thus the base memory should be less for that process. This will give you greater headroom for the memory consuming PDF operations. Because the PDF URLs are in a separate daemon process, one can also set a small value for maximum number of requests for that process to keep restoring memory usage back to a low level in case there is memory usage creep. By using daemon mode of mod_wsgi you have also moved the Python application out of the main Apache child processes and thus those process will be smaller and as a result may handle static file requests better. Because mod_wsgi gives you these more flexible means of delegating what runs in what processes, it will be interesting if this might affect in the future, when mod_wsgi starts to be adopted more, how WebFaction determines how much memory you use. For example, if you can restrict Apache to using 2 child process to handle static files and for proxying to the daemon processes, with these process then being small, eg < 10MB, one could possibly argue that you should be allowed a greater memory limit for the daemon process running the Python application. Ie., instead of allow 4 * 40MB process, why not allow 2 * 20MB + 2 * 60MB processes. That is calculate it across all processes as a combined total rather than put a maximum on the size of any one process. BTW, choosing one system over another based on perceived performance is not a good idea. The differences in performance between mod_python, mod_wsgi or fastcgi solutions get totally swallowed up as soon as you load on a big Django application, especially one that uses a database, as the bottleneck is then elsewhere. You are therefore better off choosing a solution based on ease of configuration and management and for the options it has for controlling memory usage and security. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
