> On 6 Jun 2019, at 4:20 am, Gertjan Klein <[email protected]> wrote:
> 
> Gertjan:
>>> Python 2.7 is nearing EOL, and I want to migrate the applications to Python 
>>> 3.7 (the standard Buster Python 3 version). I am seeking advice on how to 
>>> approach this.
> [...]
> 
> Graham:
>> Using mod_wsgi-express behind the original Apache acting as a proxy is one 
>> way. Just be warned that mod_wsgi-express is mostly intended for running a 
>> single WSGI application. That said, it should use less memory than your main 
>> Apache as the configuration it uses is designed to reduce memory over 
>> default Apache setup.
> 
> If I'm not mistaken, mod_wsgi_express runs in a virtualenv?

If you are using virtual environments, yes, it would be installed into that. 
Each virtual environment would have its own copy if you had more than one, 
allowing different Python versions to be used. A separate instance of it would 
be run for each application in respective virtual environments.

> My apps do as well, so that would work. I would like to use a separate 
> mod_wsgi_express for each application, though, so memory savings I don't see 
> (but are not the goal). Thanks for the links (snipped), it looks very useful!

When you use a single Apache instance to host multiple WSGI applications, you 
would either being using separate daemon process groups for each, or separate 
sub interpreters of a single process. In either case, Python code and modules 
in larger part is not shared. Each application also still has its own separate 
memory footprint.

That combined with a typical Apache installation not being setup very well for 
Python applications, means that total memory usage may not be much different, 
especially if using frameworks like Django. In fact, the better configuration 
of mod_wsgi-express may make it better overall if you weren't using daemon 
mode, as you can tune further each mod_wsgi-express instance to needs of a 
specific application. This means if you have one application that needs a multi 
process configuration, you aren't then bloating out size used by others 
unnecessarily. Memory use would be least of my concerns.

> 
> Graham:
>> These talk about mod_wsgi-express running in a container, but you don't need 
>> to and discussion is still relevant when you don't. You would instead use 
>> the `mod_wsgi-express setup-server` command to generate configuration up 
>> front and then integrate invocation of 'apachectl' it generates into your 
>> system startup system.
> 
> I am not opposed to using containers. I noticed the containers you provide 
> stop at Python 3.5. Is there any particular reason for that?

There wasn't any real interest in the community for having curated container 
images for Python web application hosting that used best practices. Everyone 
wanted to build their own from scratch. After all, docker was a shiny new tool 
and was silly to think you could deprive people of their opportunity to waste 
lots of time learning it, making lots of mistakes, but still come up with only 
a half baked solution that sort of worked. ;-)

> 
> Thanks for your input, regards,
> Gertjan.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/modwsgi.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/modwsgi/qd9158%245hqt%241%40blaine.gmane.org.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/1222F2C2-FC03-4CFA-8384-62FD31491CB9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to