On 14/12/2014, at 2:54 PM, Christiaan Stoudt <[email protected]> wrote:
> Graham,
>
> Thank you for clarifying... I had a feeling that was an option but somehow I
> didn't see it in the documentation so I assumed it was the "user=" instead.
The socket-user option was specifically added just for your issue. The
documentation is not up to date on a lot of things.
> You really do rock... So that dev version helped prove that it was using
> the UID of my website user account to access the file. I had to play with
> the sequence but finally found the right setting and the page loads. I
> tested it on another Django website I had that was pure embedded mode. I
> switched to WSGIDaemon and bam it worked and I see multiple threads, etc. My
> final config was:
>
> WSGIDaemonProcess mydomain_com user=mydomainusername group=mydomainusername
> display-name=%{GROUP} socket-user=mydomainusername
>
> Thank you SO much!
>
> So, if I could get one last bit of advice out of you I would really
> appreciate it.
>
> 1) WSGIDaemon mode is a LOT better than normal embedded mode correct? Even
> with all those threads loading, etc?
Daemon mode avoids a lot of issues that can occur with embedded mode if you
don't configure Apache very well to suit your Python web application.
Whether the use of threads is an issue really depends on what you web
application is doing and whether it is I/O bound or CPU bound.
Most of the time web applications are I/O bound as they are waiting a lot of
the time on backend database services or other services.
The mistake people make with the threads per process is that have grandiose
ideas of how many they need and provision too many. Daemon mode has some smarts
in it to protect against it being set to high, but it still consume a bit of
memory having them all even if not used because too many were specified.
> 2) Should I tweak down any of the WSGIDaemon settings like the threads or
> anything?
Depends on your specific web application.
Can't really comment without knowing the request throughout, average response
times and request queuing time relative to when Apache first accepts the
request. Knowing the capacity utilisation for the current configuration also
helps. For all of these you need monitoring in place to get the information.
> 3) I plan to move 3 of my Django domains running WSGIDaemon mode over to SSL
> (multidomain SSL on a single VPS host/IP) next so the sites are pure HTTPS.
> Is there any settings changes or optimization or concerns I should have on
> the mod_wsgi side? I'm new to SSL so just wanted to check before I reach out
> to my VPS provider to help me do the move.
None that I can think of if you intent only having them serve HTTPS.
Where people often make a mistake is where have both HTTP and HTTPS. What they
do is have separate daemon process groups for each, which only doubles memory
usage. It is possible to use a single daemon process group for both.
> Moving to SSL will be important for me so thank you for answering these last
> few questions...
>
> Regards,
> C
>
>
> On Saturday, 13 December 2014 17:44:29 UTC-8, Graham Dumpleton wrote:
>
> On 14/12/2014, at 7:11 AM, Christiaan Stoudt <[email protected]> wrote:
>
>> WSGIDaemonProcess mydomain_com user=nobody group=nobody display-name=%{GROUP}
>> WSGIProcessGroup mydomain_com
>> WSGIScriptAlias / /home/mydomain/public_html/d171p275/mydomain_com/wsgi.py
>
> The change I made was to add a 'socket-user' option to WSGIDaemonProcess. You
> need to add that option and set it to the user name which the Apache child
> worker process would be running as after mod_ruid2 switched the uid. For
> example:
>
> WSGIDaemonProcess mydomain_com user=nobody group=nobody display-name=%{GROUP}
> socket-user=username
> WSGIProcessGroup mydomain_com
> WSGIScriptAlias / /home/mydomain/public_html/d171p275/mydomain_com/wsgi.py
>
> If you don't know what mod_ruid2 is setting the uid to for some reason. Pull
> down the latest mod_wsgi from github develop branch and use it. I have
> changed the logging so it ail show what the Apache child worker process hid
> was when it was trying to connect:
>
> [Sun Dec 14 12:25:16 2014] [error] [client ::1] (13)Permission denied:
> mod_wsgi (pid=15689): Unable to connect to WSGI daemon process 'xxx' on
> '/private/var/run/wsgi.15675.0.1.sock' as user with uid=70.
>
> So if get that error, the socket-user option should specify the user given by
> the logged uid.
>
> Graham
>
> --
> 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 http://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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
