> On 13 Oct 2017, at 3:20 am, [email protected] wrote:
>
> Hi Graham,
>
> Thanks again for your help.
>
> We're still noticing some extreme slowness with initial page-loads. For
> example, I fire off 4 requests to 4 different hosts, 3 return quickly and one
> takes a very long time. Subsequent requests all go through quickly, and then
> some time later, we'll see the same pattern -- some requests taking a long
> time, followed by fast responses.
>
> Here is the updated config. I wonder if anything jumps out at you? PS --
> we're using single-threaded because this is a Django application, but it may
> be possible to use multiple threads since we're not doing anything that
> crazy...do you think that would resolve the issue?
>
> WSGIRestrictEmbedded On
> WSGISocketPrefix /var/run/wsgi
> WSGIScriptAlias /api /path/to/wsgi_file.wsgi
> WSGIDaemonProcess proj_name user=apache group=apache processes=15 threads=1
> display-name=the-proj-name
> WSGIProcessGroup proj_name
> WSGIApplicationGroup %{GLOBAL}
Change to:
WSGIRestrictEmbedded On
WSGISocketPrefix /var/run/wsgi
WSGIDaemonProcess proj_name user=apache group=apache processes=15 threads=1
display-name=the-proj-name
WSGIScriptAlias /api /path/to/wsgi_file.wsgi process-group=proj_name
application-group=%{GLOBAL}
By using process-group and application-group options to WSGIScriptAlias,
instead of separate WSGIProcessGroup and WSGIApplicationGroup, it will pre-load
the WSGI application when the process starts, rather than on first request to
the process. They may give you some extra time.
Graham
>
>
> <VirtualHost *:80>
> ServerName sub1.host.com <http://sub1.host.com/>
> HostSpecificDirective some-value1
>
> <Location /some-path>
> (host specific config)
> </Location>
> </VirtualHost>
>
> <VirtualHost *:80>
> ServerName sub2.host.com <http://sub2.host.com/>
> HostSpecificDirective some-value2
>
> <Location /some-path>
> (host specific config)
> </Location>
> </VirtualHost>
>
> etc...
>
> 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, [email protected] <> 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 <http://sub1.host.com/>
> # subdomain-specific logging, etc
> </VirtualHost>
>
> <VirtualHost *:80>
> ServerName sub2.host.com <http://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, [email protected]
>> <http://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 <http://sub1.host.com/>
>> # subdomain-specific logging, etc
>> </VirtualHost>
>>
>> <VirtualHost *:80>
>> ServerName sub2.host.com <http://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 <http://googlegroups.com/>.
>> To post to this group, send email to mod...@ <>googlegroups.com
>> <http://googlegroups.com/>.
>> Visit this group at https://groups.google.com/group/modwsgi
>> <https://groups.google.com/group/modwsgi>.
>> For more options, visit https://groups.google.com/d/optout
>> <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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <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.
