Hey Graham, Thanks a ton, that is a great article! Looks like I was doing everything right, so I started to play with my setup more and it turns out that my testing was invalid because apparently chrome will only open up to a certain number of open sockets to a host at a time, so by using it to test exhausting my processing group by opening several tabs, I was causing chrome to refuse to open any more even though the url would work in other browsers but it gave me the impression that the url was hung server side. Just typing this up in case someone else comes across it. Thanks again!
-Reece On Thu, Jun 21, 2018 at 10:09 PM, Graham Dumpleton < [email protected]> wrote: > This is exact concept is explained in: > > * http://blog.dscpl.com.au/2014/02/vertically-partitioning-python-web.html > > There are a few issues. > > Double check that your Location patterns are in fact matching the URLs and > sending them t the correct daemon process group. > > * http://modwsgi.readthedocs.io/en/develop/user-guides/ > checking-your-installation.html#embedded-or-daemon-mode > > Use: > > WSGIApplicationGroup %{GLOBAL} > > in each respecting Location block. Don't name the application group > differently. It is better to force use of main interpreter, which is what > %{GLOBAL} does. > > The shutdown-timeout is ridiculously larger and doesn't actually help in > the case of an Apache restart as Apache force kills daemon processes after > 3 seconds in that case anyway. > > If you are triggering daemon process restarts by sending them signals, > then look at graceful-timeout instead. > > * http://modwsgi.readthedocs.io/en/develop/configuration- > directives/WSGIDaemonProcess.html > > Overall what you are doing conceptually is correct, but you do need to > provisions adequate processes/threads in each daemon process group for the > respective throughput you expect. > > Further, you need to also consider what Apache MPM process/threads > settings are, as the Apache child worker process which they apply to, still > have to proxy your requests, so there needs to be adequate capacity there > for proxy number of concurrent requests. If you have played with those and > have those set very low, that will be the blocking point and the requests > will be queued up there. > > What are the Apache MPM settings you are using? > > Also look at various other timeout options for WSGIDaemonProcess in the > docs and what they do as may be appropriate to set various those so can > better recover from blocking and backlogging. The default options out of > the box unfortunately aren't the best experience. > > Graham > > > On 21 Jun 2018, at 10:40 pm, Reece <[email protected]> wrote: > > 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. > > > -- > 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.
