Graham,

Thank you again for all the information and help!  I really appreciate it. 
 Have a lovely holiday...

Regards,
C

On Monday, 15 December 2014 02:39:51 UTC-8, Graham Dumpleton wrote:
>
>
> On 14/12/2014, at 2:54 PM, Christiaan Stoudt <[email protected] 
> <javascript:>> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> 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.

Reply via email to