I set a single thread just to make it easier to trigger the scenario I'm testing.
What we have is a single django app, but I'd like two different process pools to handle two different urls within that same app, so that even if one url (and it's specified process pool) is being hammered with long running queries then it does not impact the second url (and the second process pool) at all. e.g. if one url becomes unresponsive due to backend problems, I want the second url to still work. Is that kind of scenario possible? -Reece On Wed, Jun 20, 2018 at 7:49 PM, Peter Lai <[email protected]> wrote: > Running a single thread per process would explain why Django locks your > UI, because it's unable to service more than a single request at a time. Is > there a reason why you are running only a single thread? > > Now, if increase the number of threads and still running into long running > processes that does not improve due to thread contention, then you're going > to need to target another part of the workload. Long running processes that > monopolize the entire interpreter should be decoupled from the > RequestHandler by using task queues like Celery or Advanced Python > Scheduler to dispatch the long-running processes and free up the UI. > > Finally, I'm not exactly sure how ScriptAlias / and trying to set the > ProcessGroup in separate Locations of /subdirectories play (does apache > actually coalesce any virtual <Location> created by the alias with the > child subdir location WSGIProcessGroup directives?) > > > On Wednesday, June 20, 2018 at 7:08:35 PM UTC-4, Reece Pegues wrote: >> >> We have a product using mod_wsgi with django on linux (centos6). We >> have some very long running api commands, and so we'd like to have things >> separated so that the api cannot lock users out of the user interface. To >> do this I thought I should be able to use process groups to separate out >> the two, so something along these lines: >> >> >> WSGIDaemonProcess product user=django group=django processes=3 threads=1 >> shutdown-timeout=600 display-name=product python-home=/usr/lib/venv >> WSGIDaemonProcess api user=django group=django processes=3 threads=1 >> shutdown-timeout=600 display-name=api python-home=/usr/lib/venv >> >> WSGIScriptAlias / /usr/lib/venv/lib/python2.7/si >> te-packages/our_project/wsgi.py >> >> <Location ~ "/rest"> >> WSGIApplicationGroup api >> WSGIProcessGroup api >> WSGIRestrictProcess api >> Require all granted >> </Location> >> >> <Location ~ "/(ui|product)"> >> WSGIApplicationGroup product >> WSGIProcessGroup product >> WSGIRestrictProcess product >> Require all granted >> </Location> >> >> >> At first this appeared to work, I set a particular api to just do >> time.sleep(600) and made several requests to it, and I was still able to >> use the UI... but only for a while. At some point the UI stopped accepting >> requests as well. I guess my question is, am I doing this right, or are >> there other considerations I need to take in order to now allow certian >> long-running URLs to freeze up the entire process pool? >> >> Thanks! >> -Reece >> >> >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
