Thank you, Graham. I cannot tell you how much I appreciate your help here
(as does my employer). I'm new to configuring Apache/mod_wsgi in anything
other than a cookie-cutter way, so your help is invaluable.
I'll spend some time with your reply and make sure I understand everything
you've written.
Thanks again.
On Tuesday, October 3, 2017 at 5:37:51 PM UTC-5, Graham Dumpleton wrote:
>
>
> On 4 Oct 2017, at 3:44 am, charles...@propylon.com <javascript:> wrote:
>
> I'd add that in each VirtualHost we are specifying:
>
> <VirtualHost *:80>
> ...
> WSGIScriptAlias /path /path/to/wsgi-file.wsgi
> WSGIDaemonProcess proj_name
>
>
> You can't be using exactly that, as mod_wsgi would complain about the
> repeating use of 'proj_name' in each VirtualHost as you can only use it
> once for a daemon process group.
>
> If you intend to use daemon mode, with one Django instance handling all
> requests for all host names, you should be using:
>
> WSGIRestrictEmbedded On
> WSGIScriptAlias /path /path/to/wsgi-file.wsgi
> WSGIRestrictEmbedded proj_name processes=10 threads=1
> WSGIProcessGroup proj_name
> WSGIApplicationGroup %{GLOBAL}
>
> <VirtualHost *:80>
> ServerName sub1.host.com
> # subdomain-specific logging, etc
> </VirtualHost>
>
> <VirtualHost *:80>
> ServerName sub2.host.com
> # subdomain-specific logging, etc
> </VirtualHost>
>
> That is, one instance of WSGIDaemonProcess outside of all virtual hosts.
>
> You are also not showing that you are using WSGIProcessGroup, which means
> you are actually running everything in embedded mode. Worse is that you
> weren't using WSGIApplicationGroup to force use of main interpreter context
> using %{GLOBAL}, meaning that every site had its own Django instance in a
> separate sub interpreter. Multiply that by the number of Apache child
> worker processes and you would have had a huge number of instances and
> likely every request was loading a new one until all processes had been
> primed with a copy of all.
>
> The WSGIRestrictEmbedded is to ensure nothing accidentally runs in
> embedded mode, by disabling its use.
>
> Do be aware you are still going to have 10 copies of your application
> because daemon mode is set to 10 processes and one thread.
>
> If your application is thread safe, a single thread per process is not
> usually a good idea, unless your application is super CPU intensive, which
> they aren't. Usually better to have 3-5 threads. So I would suggest
> processes=5 threads=3 as starting point.
>
> BTW, can you confirm that the target WSGI script file is the same for each
> virtual host.
>
> Graham
>
> </VirtualHost>
>
> And those directives are repeated for each virtualhost.
>
> On Tuesday, October 3, 2017 at 11:33:35 AM UTC-5, charles...@propylon.com
> wrote:
>>
>> We have a Django application that needs to respond to a number of
>> different sub-domains. By using Django middleware, we are able to avoid
>> having to run a separate instance of the Django application for each
>> virtualhost. We need to specify a virtualhost for each subdomain as there
>> is some Apache-level configuration that must be specified for each hostname.
>>
>> The problem I'm experiencing is that the server is very slow to respond
>> at first. Sometimes the first request can take 15-30 seconds to go through.
>> Load on the server is minimal, and typically once the first request goes
>> through, the server is quite responsive. When making a request to a
>> different host, however, we again will encounter slowness.
>>
>> Our apache config for the site looks something like this:
>>
>> WSGIScriptAlias /path /path/to/wsgi-file.wsgi
>> WSGIDaemonProcess proj_name processes=10 threads=1
>>
>> <VirtualHost *:80>
>> ServerName sub1.host.com
>> # subdomain-specific logging, etc
>> </VirtualHost>
>>
>> <VirtualHost *:80>
>> ServerName sub2.host.com
>> # subdomain-specific logging, etc
>> </VirtualHost>
>>
>> # etc, for ~50 subdomains
>>
>> Can you help me understand what might be going on here? I have tried to
>> read the documentation, but it's very difficult to parse.
>>
>
> --
> 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+u...@googlegroups.com <javascript:>.
> To post to this group, send email to mod...@googlegroups.com <javascript:>
> .
> 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.
