Hi Kevin,
I'll explain it from a user point of view. This is written assuming the
following apache configurations:
WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess Port8123 processes=2 threads=4
python-path=/home/jason/DevLevel.2/TCM/Python
Listen 127.0.0.1:8123
<VirtualHost 127.0.0.1:8123>
ServerName _default_
DocumentRoot /home/jason/DevLevel.2/TCM/Web/MemberSite
AddDefaultCharset UTF-8
RewriteEngine on
RewriteRule ^/m$ /mobile/ [R,L]
RewriteRule \.(py|pyc|pyo|wsgi)$ - [F]
WSGIScriptAlias /api/callcenter
/home/jason/DevLevel.2/TCM/Web/MemberSite/api/callcenter/index.wsgi
WSGIScriptAlias /mobile
/home/jason/DevLevel.2/TCM/Web/MemberSite/mobile/index.wsgi
WSGIScriptAlias / /home/jason/DevLevel.2/TCM/Web/MemberSite/index.wsgi
WSGIProcessGroup Port8123
LogLevel info
ErrorLog /home/jason/DevLevel.2/TCM/apache-error.log
</VirtualHost>
In the above instance, mod_wsgi will create 2 python processes with 4
threads per process. Any one of these threads is eligible for receiving a
request at any time it is not already handling one.
This brings up several considerations:
1. You cannot store application-data in-process and expect it to be
available to all requests.
2. You cannot write to global in-process data and expect that another
request will not be clobbering your write at the same time, unless you use
thread locks.
In practice, we do the following:
1. Make use of a class derived from threading.Local in order to hold
database connections, etc... In practice, this means 1 DB connection per
thread, but that has never been an issue.
2. Use redis as the place to keep shared data (which works across servers,
nicely).
3. Except during import, we do not write to class attributes, module
attributes, or any other global data structures.
4. Use nginx on the front end. Nginx will buffer requests and responses
(up to 1MB by default) before or after involving apache. Therefore, even a
slow client will not "hold apache up" and cause a problem. mod_wsgi apps
can be freakishly fast too.
5. Use nginx to handle static content and authenticated file downloads.
Look up x-accel-redirect for an overview of this.
If it would be helpful, here is a sample nginx conf for the above. Note
that we are using a different port per application, which keeps security
tighter, and less to configure in apache.
server
{
listen 192.168.50.12:80;
server_name member.thecallingmaniac.com.2.jason.step.appcove.net;
location ^~ /FileStruct/
{
internal;
alias /var/lib/FileStruct/TCM_2/;
}
location ~ \.(gif|jpg|png|ico|xml|html|css|js|txt|pdf)$
{
root /home/jason/DevLevel.2/TCM/Web/MemberSite;
expires max;
}
location /
{
add_header Cache-Control 'no-cache, no-store, max-age=0,
must-revalidate';
add_header Expires 'Thu, 01 Jan 1970 00:00:01 GMT';
proxy_pass http://127.0.0.1:8123;
}
}
Multiple threads have never been a problem, and we've run from 1 thread and
process up to over 100 per app.
Take care,
Jason
On Thu, Oct 25, 2012 at 3:33 PM, Kevin G. <[email protected]> wrote:
> Coming from the world of apache-prefork and mod_perl, we're about to roll
> out our first django application using
>
> WSGIDaemonProcess our-appname processes=6 threads=15
>
> and we're having some discussion about what the "threads=15" means for our
> Python code. Is our Python code now multi-threaded? Do we now have to
> worry about shared data and concurrency and locking and thread-safe C
> libraries?
>
> The wsgi documentation says "The aim of mod_wsgi is to implement a simple
> to use Apache module which can host *any Python application* which
> supports the Python WSGI interface," which seems to imply that there is
> nothing special our code has to worry even though we're running with
> "threads=15", but it doesn't say so explicitly.
>
> Could someone explain what the programming model is here in terms that
> would be comprehensible to someone coming from the single-threaded
> apache-prefork world?
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/modwsgi/-/-NPphiHX5ZoJ.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
