first off, i apologize if my explanations/questions are not clear.
please ask for detailed explanations where necessary.

topic: targeting easier wsgi application releases/versioning with
advanced monitoring and runtime reconfiguration

knowing that it's possible to configure apache/mod_wsgi to support
serving different wsgi application release/version (easiest way being
through wsgi script) mentioned in this and similar threads:
http://groups.google.com/group/modwsgi/browse_thread/thread/3a0e23444992f35f/bf39048caa8b9658
there are still some issues that are now quite clear.

assuming structure in /var/www/wsgi/example.com/ similar to:
------------------------------------------------------
  |- media/
  |- releases/
      |- r1/
         |- project.wsgi # wsgi script
         |- env # virtualenv
         |- static # static files
      |- r2/
         |- project.wsgi # wsgi script
         |- env # virtualenv
         |- static # static files

apache/mod_wsgi is somehow configured to handle example.com domain,
example.com and www.example.com pointing to release somehow marked as
"stable" while r<n>.example.com pointing to related release/version.

if i define WSGIDaemonProcess with threads=5 (and other similar
settings) it will be applied for all but what if i want different
settings when accessing release not marked as "stable".
can i have 5 threads for release marked as "stable" (not shared with
other releases) and only 1 thread when accessing r10.example.com and
other r<n>.example.com releases not marked as "stable".
now that i have different settings for each release it should also be
possible to restrict access by ip or similar apache options.
since every release has static files, it should point to r10/static/
when accessing r10.example.com/static/.
also, separate logs for each release as addition to standard logs for domain.

arguably, this can be achieved with current mod_wsgi implementation.
although, not in an easy way.
note that i would personally like to achieve this in apache/mod_wsgi
configuration and not in wsgi scripts.

configuration of additional logs per wsgi application to store "TIME
CPU-USAGE MEMORY-USAGE DISK/IO-USAGE THREADS ..." every <n> seconds.
based on application usage (calculated trending?) and additional
configuration options increase/decrease resources wsgi application can
use.
if server hosts wsgi applications that are active only in a specific
period of the day (or something similar) and since there is some basic
trending calculated (or configured based on trending/logs) wsgi
application should be pushed to swap/disk and use no memory.
also, if wsgi app is at max resources configured and system has
resources (cpu, memory, ...) available it should enable wsgi app to
use additional resources, maybe with threads=auto or something more
appropriate.

i'm also interested in something like this:
WsgiConfigurationScript my_config_script.py
WsgiConfigurationScriptInterval 300 # seconds
which would result in calling some function in my_config_script.py
every 5 minutes and based on script output reconfigure settings at
runtime.
code i would personally put inside would do something like:
- if it's 1 am set threads=1, push to swap/disk or something similar
- if it's 7 am reset all settings to default/static apache configuration

please note that by "new features" i'm also considering an in-depth
document(s) on how to setup something, probably mostly because
currently it's not obvious how to do something in an easy way.

i have more stupid ideas what i would like to be able to do but am
aware that this sounds stupid enough so i won't be mad if this is
ignored.

also, is there something new in httpd 2.3 that will affect mod_wsgi in any way?

Aljosa Mohorovic

-- 
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.

Reply via email to