Re: [modwsgi] Single WSGI application servicing multiple virtualhosts?
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 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 this group, send email to mod...@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.
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
[modwsgi] Re: Single WSGI application servicing multiple virtualhosts?
I'd add that in each VirtualHost we are specifying: ... WSGIScriptAlias /path /path/to/wsgi-file.wsgi WSGIDaemonProcess proj_name 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.
[modwsgi] Single WSGI application servicing multiple virtualhosts?
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.
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
>&g
