mod_wsgi has the maximum number of requests restart, so it must know a way (e.g.; "I;m no longer sending requests to this process, and all pending requests have completed, so I'll send a signal"), but how to get it to invoke that process will require someone else's input.
On Wed, Mar 16, 2016 at 1:29 PM, Kent Bower <k...@bowermail.net> wrote: > Interesting idea.. yes, we are using multiple threads and also other > stack frameworks, so that's not straightforward, but worth thinking > about... not sure how to approach that with the other threads. Thank you > Bill. > > On Wed, Mar 16, 2016 at 1:11 PM, Bill Freeman <ke1g...@gmail.com> wrote: > >> I don't know about nginx, but one possibility, if the large memory >> requests are infrequent, is to detect when you have completed one and >> trigger the exit/reload of the daemon process (calling sys.exit() is not >> the way, since there could be other threads in the middle of something, >> unless you run one thread per process). >> >> On Wed, Mar 16, 2016 at 7:50 AM, Kent <jkentbo...@gmail.com> wrote: >> >>> I'm looking for a very brief high-level pros vs. cons of wsgi under *apache >>> *vs. under *nginx *and then to be pointed to more details I can study >>> myself (or at least the latter). >>> >>> Our application occasionally allows requests that consume a large amount >>> of RAM (no obvious way around that, they are valid requests) and >>> occasionally this causes problems since we can't reclaim the RAM readily >>> from apache. (We already have tweaked with and do use >>> "inactivity-timeout". This helps, but still now and then we hit problems >>> where we run into swapping to disk.) >>> >>> I'm wondering if nginx may solve this problem. I've read much of what >>> you (Graham) have had to say about the memory strategies with apache and >>> mod_wsgi, but wonder what your opinion of nginx is and where you've already >>> discussed this. I've read articles I could find you've written on nginx, >>> such as "Blocking requests and nginx version of mod_wsgi," but wonder if >>> the same weaknesses are still applicable today, 7 years later? >>> >>> >>> Thank you very much in advance! >>> Kent >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to modwsgi+unsubscr...@googlegroups.com. >>> To post to this group, send email to modwsgi@googlegroups.com. >>> Visit this group at https://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "modwsgi" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/modwsgi/wyo2bJP0Cfc/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> modwsgi+unsubscr...@googlegroups.com. >> To post to this group, send email to modwsgi@googlegroups.com. >> Visit this group at https://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to modwsgi+unsubscr...@googlegroups.com. > To post to this group, send email to modwsgi@googlegroups.com. > Visit this group at https://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
