On Feb 12, 7:31 pm, Christopher Arndt <[EMAIL PROTECTED]> wrote: > Lukasz Szybalski schrieb: > > > On Feb 11, 2008 10:53 AM, Chris Arndt <[EMAIL PROTECTED]> wrote: > >> Here are some example init scripts from the documentation: > > >>http://docs.turbogears.org/1.0/RoughDocs/InitScripts > > > What is the advantage of using init script vs using apache and > >mod_wsgi with turbogears app? > > You could use this if you wanted to run your TG app stand-alone > (possibly several instances) behind a reverse proxy/load balancer.
One has to consider here what the motivations are for doing this however. There are actually two primary reasons why you might want to do this. The first is the Python GIL problem. If you run a single multithreaded TG process then your application generally may not be able to make good use of a multi core or multi processor system. Thus running multiple TG processes on the same box and spreading requests across them can help. For this situation though, on UNIX systems at least, Apache is multi process to begin with, so you get this for free if using embedded mode of mod_wsgi. Even if using daemon mode of mod_wsgi you can set it up to run multiple processes. The big benefit of running TG in embedded mode of mod_wsgi with Apache is that Apache will automatically scale up to meet demand. That is, as more requests come in that current processes can handle, it will create more. When requests drop off, it will kill off the no longer needed processes. This is something that running TG instances manually with a separate supervisor system you cannot do. Thus, if using a separate supervisor system you are stuck with a fixed number of TG processes. You therefore need to create what is needed for maximum demand. Because the processes will always be running, they will always be consuming maximum amount of memory. With Apache, it will kill off process not needed and reclaim memory. One can also setup Apache to recycle processes after a set number of requests if your application is leaking memory for some reason. The second reason for spreading requests is where the box itself just doesn't have enough power to run the application for the number of requests it gets, whether or not multiple processes are already being used. In this case you would want to load balance across multiple TG instances on different boxes. In this sort of situation using Apache to perform the load balancing may not be the best solution and using purpose built load balancing proxies such as Pound or Squid may be more appropriate. Anyway, in this situation, there is nothing to stop the front end proxy proxying to Apache instances running TG under mod_wsgi. In all, it really depends on how serious a setup you need to develop. For bigger systems the scalability features of the Apache configuration may be a better choice. If your system isn't going to be that big, then what you should really look at is what you perceive as being the easier to setup and manage for your particular application. > > If you run the tg app with apache,mod_wsgiyou don't need a supervisor > > since apache handles that. > > But there's more to supervisor than just starting/stopping your app. For > example you can monitor/control your apps remotely and you can give > permission to control some apps to other persons without the need to > give them a shell account. You may not have to give them a shell account, but you still have to give them some sort of web interface to control it. The same thing can be done with Apache. When using mod_wsgi daemon mode one can also easily ensure that different applications run as different users and thus users can independently restart just their application processes without needing to restart Apache as a whole. > And it captures stdout of your app and rotates the resulting log files. Any application that wants to say it is WSGI compliant and at the same time be portable to different WSGI hosting solutions, shouldn't be outputing direct to stdout. This is because some WSGI hosting solutions use stdout as the means of communicating with the web server. Thus an application which outputs to stdout can end up stuffing log messages into the response by mistake. That said, Apache also captures program output and stuffs it in log files and any good Apache/OS installation will have log file rotation setup for Apache. Thus not sure why this is being highlighted. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
