Re: [modwsgi] Single WSGI application servicing multiple virtualhosts?
And I think I answered my own question. Besides the configuration issues we
originally had, we had a second networking issue going on. Sorry to have
wasted your time today, I appreciate the guidance.
On Thu, Oct 12, 2017 at 5:09 PM, Charles Leifer (Propylon) <
charles.lei...@propylon.com> wrote:
> Unfortunately that didn't seem to resolve the issue.
>
> If it helps, I'm not seeing load on the server when the request hangs. In
> the browser, it seems to be hanging while establishing a connection in the
> first place, as opposed to doing any sending/waiting-to-receive.
>
> On Thu, Oct 12, 2017 at 4:41 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>>
>> On 13 Oct 2017, at 3:20 am, charles.lei...@propylon.com 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
>>
>>
>>
>>
>> ServerName sub1.host.com
>> HostSpecificDirective some-value1
>>
>>
>> (host specific config)
>>
>>
>>
>>
>> ServerName sub2.host.com
>> HostSpecificDirective some-value2
>>
>>
>> (host specific config)
>>
>>
>>
>> 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, charles...@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.
Re: [modwsgi] Single WSGI application servicing multiple virtualhosts?
> On 13 Oct 2017, at 3:20 am, charles.lei...@propylon.com 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
>
>
>
> ServerName sub1.host.com
Re: [modwsgi] Single WSGI application servicing multiple virtualhosts?
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}
ServerName sub1.host.com
HostSpecificDirective some-value1
(host specific config)
ServerName sub2.host.com
HostSpecificDirective some-value2
(host specific config)
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, charles...@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+u...@googlegroups.com .
> To post to
