> On 4 Oct 2017, at 3:44 am, charles.lei...@propylon.com wrote:
>
> I'd add that in each VirtualHost we are specifying:
>
>
> ...
> 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}
ServerName sub1.host.com
# subdomain-specific logging, etc
ServerName sub2.host.com
# subdomain-specific logging, etc
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
>
>
> 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
>
>
> ServerName sub1.host.com
> # subdomain-specific logging, etc
>
>
>
> ServerName sub2.host.com
> # subdomain-specific logging, etc
>
>
> # 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+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.
