2009/11/18 Daan Davidsz <[email protected]>:
>
>
> On Nov 18, 10:47 am, Graham Dumpleton <[email protected]>
> wrote:
>> I am curious what mix of groups, processes and threads you thought
>> might give you flexibility you need for what you have in mind. Can you
>> post the updated configuration?
>
> Sure, here it is:
>
> ####################################################################
> WSGIDaemonProcess cms threads=8 display-name=%{GROUP}
> WSGIDaemonProcess sites threads=8 display-name=%{GROUP}
> WSGIDaemonProcess other threads=8 display-name=%{GROUP}
> WSGIDaemonProcess single threads=1 processes=4 display-name=%{GROUP}
>
> WSGIRestrictProcess cms sites other single
>
> WSGIProcessGroup %{ENV:site.process_group}
> WSGIApplicationGroup %{ENV:site.application_group}
>
> SetEnv site.process_group sites
> SetEnv site.application_group %{RESOURCE}
> ####################################################################
>
> At default all scripts (probably one per website) will be assigned to
> the "sites" processgroup and will get their own applicationgroup. Only
> for the CMS I will use the cms processgroup.
BTW, I presume this configuration works, or is it still being set up?
Suggest you use the following WSGI test script to verify what process
group and application group is being used.
import StringIO
import mod_wsgi
def application(environ, start_response):
status = '200 OK'
output = StringIO.StringIO()
print >> output, 'process_group: %s' % mod_wsgi.process_group
print >> output, 'application_group: %s' % mod_wsgi.application_group
output = output.getvalue()
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
This presumes mod_wsgi 2.4 or later being used and would have to be
modified for older mod_wsgi versions to get the process group and
application group information out of 'environ' dictionary.
>> How hard or easy that is is going to be governed by what Python web
>> framework you are using. Some can't handle multiple databases, others
>> can.
>
> That's the kicker; I'm not using any other framework than my own
> directly on top of mod_wsgi. Multiple database support, dynamic "CMS
> Module" loading, URL parsing and a simple Document/ORM DB model are
> some things that have been implemented already.
That certainly helps, but at the same time means more work for you.
I might suggest you have a look at Werkzeug. It doesn't mandate a
specific database adapter or ORM layer but still provides a lot of
useful infrastructure for constructing web applications so you aren't
doing everything from scratch.
Graham
--
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=.
