A few corrections. On Sep 21, 6:43 pm, Idan Gazit <[email protected]> wrote: > Short answer: mod_wsgi is awesome. I don't use mod_python anymore if I > can help it. > > Long(er) answer: mod_wsgi isn't the perfect solution but it works much > better than mod_python right now. > > With mod_python, each apache thread/worker process/etc must load a > copy of the python interpreter into memory.
No, that isn't quite what happens. Read: http://blog.dscpl.com.au/2009/03/python-interpreter-is-not-created-for.html Overall, mod_python and mod_wsgi behave exactly the same. The only difference is that by default, mod_python uses one Python sub interpreter per virtual host, where as mod_wsgi by default allocates a sub interpreter to each mounted WSGI application. > This has several bad side > effects: > > 1. If you have more than one site run off the same apache, then EVERY > instance of apache threads/workers will have a whole python > interpreter in their context. Each process will have a Python interpreter for the relevant context, not each thread. > That's quite a few megs of ram per > request, even requests for my_small_image.jpg. You shouldn't be serving static files from your Python web application. When Apache is properly configured, the serving of static files doesn't go anywhere near the Python code. > 2. If you have more than one python site on the same apache, you > cannot isolate them from one another, because the same python > interpreter is loaded for them all. Wrong. By default mod_python uses one per virtual host. You can use the mod_python PythonInterpreter directive to override this and allocate a separate sub interpreter for each application instance. This isn't necessary with mod_wsgi as a separate sub interpreter per mounted WSGI application is the default already. > What happens if you need v1.0 of a > library for this app and v1.1 for another? Can't do it with mod_python > AFAIK. Use PythonInterpreter directive properly and you can do this. > In mod_wsgi, each site can have its own private python > virtualenv. Only by virtue of fact that each WSGI application by default gets a separate sub interpreter. > There's a lot of smaller reasons for using mod_wsgi but based on those > two reasons, I would warmly recommend the usage of mod_wsgi today. > I've found it to be stable, efficient, and much less resource- > intensive than mod_python. I'd also suggest reading: http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html http://code.google.com/p/modwsgi/wiki/VirtualEnvironments http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading Graham > -I > > On Sep 21, 2009, at 11:19 AM, Ahik Man wrote: > > > > > Hello, > > > There are some articles (like the one bellow) that claimed that > > mod_wsgi is better then mod_python. > > Is anybody having a real experience with comparison like that? > > Any recommendations related to mod_wsgi? > > >http://www.technobabble.dk/2008/aug/25/django-mod-wsgi-perfect-match/ > > > Thanks, > > Ahik > > > > > > > smime.p7s > 3KViewDownload --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "PyWeb-IL" 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/pyweb-il?hl=en -~----------~----~----~----~------~----~------~--~--- _______________________________________________ Python-il mailing list [email protected] http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il
