Thank you Graham, I'll look into mod_wsgi -- that looks very promising. I have another follow-up question about multiple-app design -- and I'll give the whole story so it makes sense where I'm coming from:
Currently, we have one big database with many tables, then a mess of pages that do various functions (I think this is pretty typical of many websites). We're moving to a MVC approach because it seems to make more sense (routes/orm/etc). Now I'm having trouble deciding what to split into separate apps, what to split into controllers, how to share models/templates/static files between the apps. I've just gotten to the point that I have (working) common directories for templates, template filters, models and static files. But upon reaching that point, I step back and wonder, "Does it make more sense to combine these apps into a single app with several controllers? Am I completely misusing the Pylons model?" For instance... 1) Every app will require authentication - which is based on the users table in the (common) database... and I import user.py (from the common model dir) for that purpose. 2) Every app will use the same db. That means that I can't run (or can I?) an app by itself, because it requires a db that resides up a level. I guess my question boils down to (at least in part): Should an app be a standalone app? Thanks, Matt Haggard On Jan 2, 8:47 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On Jan 3, 5:14 am, Matt Haggard <[EMAIL PROTECTED]> wrote: > > > > > I'm (in the process of) using pylons in a production environment and > > still have a few questions: > > > 1) Do I really have to restart the server every time I make a change > > (controller/model)? I can foresee making many changes and some which > > require immediate attention, but restarting the server in the middle > > of the day would not be an option. So, do I have to make changes at > > night? Is there no way for the server to adopt the changes without > > killing all connections? > > > 2) The system will be composed of multiple apps... (perhaps as many as > > 20 or more) so would it be better (if I need to restart after every > > change) to have all the apps served by their own servers? I mean, is > > it better to have 20 instances of the paster server if uptime is such > > a priority? > > > 3) In serving several apps (thanks to Ian Bicking for the help to get > > that going!) like this: > > [composite:main] > > use = egg:Paste#urlmap > > / = config:home_app/development.ini > > /app2 = config:app2/development.ini > > ... > > > how do I make app2 aware that all of his urls are based off of /app2? > > well... actually, it is already aware of that. I'm really asking: Is > > there a way for app2 to know that the home directory is just > > plain / ? This comes up because I use a shared repository for images > > and when I reference images from app2 with src="images/something.jpg" > > it looks for the image at the > > urlhttp://127.0.0.1:5000/app2/images/something.jpg > > instead ofhttp://127.0.0.1:5000/images/something.jpg. Also, I'd like > > for app2 to be able to link back to / without explicitly hard-coding > > that url (I can see in the future bumping everything up a directory... > > making / into /section and /app2 into /section/app2) > > > Am I just going about this the wrong way? > > Many Pylons folks have an aversion to mod_wsgi and will refuse to use > it on religious grounds without even trying it, but the problems you > are trying to solve are exactly the sort of the things that mod_wsgi > is really good for. This is because mod_wsgi handles both the restart > case as well as the problem of splitting up a monolithic application > to run across multiple distinct processes. The steps required to do > this are relative easy and don't require having to setup lots of > distinct server instances each with a supervisor system as Apache/ > mod_wsgi will handle that all for you automatically. > > Starting with separation of applications into distinct processes to > allow them to be individually restart, one would take your composite > application and create separate .ini files for each application. One > would just then mount them as separate WSGI applications. For example: > > WSGIScriptAlias /app2 /some/path/app2.wsgi > WSGIScriptAlias / /some/path/home_app.wsgi > > Leave it like that and all you have done is separated the applications > so that they run within distinct sub interpreters in the same > processes. Add daemon processes to the mix though and you can delegate > each to run in a separate process and/or processes. > > WSGIDaemonProcess app2 threads=25 > WSGIScriptAlias /app2 /some/path/app2.wsgi > <Location /app2> > WSGIProcessGroup app2 > WSGIReloadMechanism Process > </Location> > > WSGIDaemonProcess home_app threads=25 > WSGIScriptAlias / /some/path/home_app.wsgi > <Location /> > WSGIProcessGroup home_app > WSGIReloadMechanism Process > </Location> > > Each application now runs in a separate process with 25 threads. > Having enabled process reload mechanism available with mod_wsgi 2.0, > to restart an application all you need to do is touch (ie., change > modification time) of the WSGI script file for that application and it > wll be automatically restarted prior to next request it receives. The > restart of that application doesn't affect other applications not > require Apache as a whole to be restarted. > > The contents of those WSGI script files is pretty trivial and just > setup the WSGI application entry point. > > import os, sys > sys.path.append('/usr/local/pylons/home_app') > > from paste.deploy import loadapp > > application = loadapp('config:/usr/local/pylons/home_app/ > development.ini') > > Although relatively easy to setup, it should do pretty well what you > want. > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
