Re: [Web-SIG] multi-threaded or multi-process wsgi apps
Graham Dumpleton wrote: package. You can if appropriate even use a combination of both modes. So these would just be seperate sections in apache's config files? For example, run Django in embedded mode for best performance, Why does this give best performance? but delegate a Trac instance to run in daemon mode so it is separated out of Apache child processes, there being various reasons with Trac why you might want to do that. Such as? Each process can if necessary have multiple Python sub interpreters, and is not limited to just one. This would be used where you need to run multiple applications in the same process but with sub interpreters being used as a means of separating them so they don't interfere with each other. Wow, I didn't even know this was possible.. what does dirt-simple-hello-world-like python that does this look like? (ie: does it have to reload all its config and open up its own database connections again?) Being separate processes then obviously they would need to do that. This is generally no different to how people often run multiple instances of a standalone Python web based application and then use a proxy/load balancer to distribute requests across the processes. *nods* The difficulty comes when you have to invalidate changes across processes. ZEO/ZODB is the only object system I know that does that. If you were using a relational database and/or a mapper such as SQLAlchemy, I wonder how you could poke it such that config-like changes in one process were propogated to another. That said, I wonder how SQLAlchemy handles invalidations of its object model when the underlying database changes as a result of actions by another process... ...but this is the wrong list for that. Thus generally better for each process to create its own connections etc. Reading of actual file configuration is generally a quite minor overhead in the greater scheme of things. You haven't used zope, right? ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] multi-threaded or multi-process wsgi apps
Graham Dumpleton wrote: For daemon mode, in mod_wsgi 2.0 there is also 'Process' reload mechanism as an option. Just touching the main WSGI script file entry point will cause just the processes for that daemon process group to be restarted on next request, thereby avoiding a restart of the whole Apache web server and any other hosted applications. Cool, when's 2.0 out? Thus, change your config file, whether it be actual Python code or an ini file and touch the main WSGI script file for that application. Upon the next request against that application it will detect WSGI script file has changed and will do the restart. Will that restart all processes/sub processes/threads? For other options on how to trigger automatic reloading of application process in mod_wsgi when code and/or config changes see: http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode Not sure I followed it all, but certainly looks useful :-) Latter example in this based on similar stuff that Ian has done, just customised to the setting of mod_wsgi and that one can rely on mod_wsgi to automatically restart a daemon process when killed off. Thus bit different to where this sort of idea is used elsewhere to trigger in process reload of modules on top of existing modules, which will not always work because of dependencies between modules. Yes, Zope learnt this the hard way :-( The was a Refresh add-on for a long time which 70% worked and so caused a lot of trouble... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] multi-threaded or multi-process wsgi apps
On 30/11/2007, Chris Withers [EMAIL PROTECTED] wrote: Graham Dumpleton wrote: For daemon mode, in mod_wsgi 2.0 there is also 'Process' reload mechanism as an option. Just touching the main WSGI script file entry point will cause just the processes for that daemon process group to be restarted on next request, thereby avoiding a restart of the whole Apache web server and any other hosted applications. Cool, when's 2.0 out? Release candidate for 2.0 including this feature is already available. Everything was okay for release but then decided to tweak/enhance some other features, including now finally adding means of specifying script to run when process first starts so that one can preload stuff. Thus, change your config file, whether it be actual Python code or an ini file and touch the main WSGI script file for that application. Upon the next request against that application it will detect WSGI script file has changed and will do the restart. Will that restart all processes/sub processes/threads? Where a daemon process contains multiple processes, it will result in all the processes being restarted eventually. Because the restart only happens when next request comes in, they all effectively get restarted in a cascade. This is because request hits first sub process and realises it will need to restart. Then try again and will likely hit next process in group which indicates it needs to restart as well and so on until hit process that has finished its restart. This is all transparent to user except for the slight delay due to restart of application. Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] multi-threaded or multi-process wsgi apps
On 30/11/2007, Chris Withers [EMAIL PROTECTED] wrote:
Graham Dumpleton wrote:
package. You can if appropriate even use a combination of both modes.
So these would just be seperate sections in apache's config files?
For an example see:
http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html
You just need to use mod_wsgi WSGIProcessGroup directive in
appropriate Directory or Location context to indicate that that WSGI
application or subset of an application should be delegated to a
different daemon process.
For example, run Django in embedded mode for best performance,
Why does this give best performance?
For some discussion on this see the following, including comments:
http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html
In short, everything is done in the first process to accept the
request. There is no proxying to a secondary process across another
socket connection. Also, Apache has the ability to create additional
processes on demand as server load increases. Proxy based solutions,
unless proxying to Apache as a backend, often use a fixed number of
backend processes and have no way of scaling up to meet demand by
starting up new processes automatically.
As explained in the blog it is a trade off. You get extra speed, but
there are other issues to contend with which make running multiple
applications in embedded mode at the same time problematic. But then
if wanting maximum speed you would have dedicated the one server to
that application and so the issues aren't really a problem.
but
delegate a Trac instance to run in daemon mode so it is separated out
of Apache child processes, there being various reasons with Trac why
you might want to do that.
Such as?
Python bindings for subversion need to run in main Python interpreter
as they aren't written to work properly within a secondary Python sub
interpreter. One can still force this when run in embedded mode, but
Trac can chew up a lot of memory over time, especially if GoogleBot
decides to browse every revision of your code through the Trac source
browser. Yes one should block search engines from such searching, but
even so, can be beneficial to use daemon mode as then takes main bloat
out of Apache child processes and allows one to set more aggressive
value for maximum requests so that processes are recycled and memory
reclaimed on a regular basis and reset back to idle level.
Each process can if necessary have multiple Python sub interpreters,
and is not limited to just one. This would be used where you need to
run multiple applications in the same process but with sub
interpreters being used as a means of separating them so they don't
interfere with each other.
Wow, I didn't even know this was possible.. what does
dirt-simple-hello-world-like python that does this look like?
The Python code looks exactly the same, you don't need to change
anything. In mod_wsgi it defaults to automatically using a separate
sub interpreter for each WSGI application script file. If your WSGI
applications don't clash and you want to make them run in the same
interpreter to avoiding loading multiple copies of modules into
memory, just need to use the mod_wsgi WSGIApplicationGroup directory.
For example:
VirtualHost *:80
WSGIApplicationGroup %{SERVER}
...
/VirtualHost
This will result in all WSGI applications running under a specific
virtual server (on port 80/443) using the same Python sub interpreter.
More details in:
http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives
Thus generally better for each process to create its own connections
etc. Reading of actual file configuration is generally a quite minor
overhead in the greater scheme of things.
You haven't used zope, right? ;-)
Not since last century some time. :-)
Graham
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
