Hi all!

I'm testdriving uwsgi to deploy Pyramid apps, and there's something I don't think I quite understand.

First of all, I find its ability to run Pyramid "natively" through paste.deploy (via --paster option) excellent as it removes the need for .wsgi interface module. With that, Pyramid just works out of the box.

Now, the problem I'm having is correctly understanding how threads relate to uwsgi. I understand Python threads are not translated directly to OS threads, there's GIL so basically there is always ONE stream of code running at the same time per process, even with multiple CPUs.

With that in mind, my reasoning is simple: use X processes to provide "real" concurrency, and within each process have Y (GIL'ed) threads that will further boost the concurrency on iowaits (database interaction, etc...). Finding optimal X and Y is what I'm now doing for my setup.

Using uWSGI option --threads seems to launch actual OS threads within the process (as observed by htop) which was not my intention and then I'm not really sure how it works internally. Using --single-interpreter does not change anything, and the docs say it means Python's "multiple interpreters" (multiple isolated apps per process) concept will not be used, which is what I think I need.

I am still trying to understand 100% Python's concept of multiple interpreters and how it all fits to threads and processes with mod_wsgi.

Can you guys help me understand this deployment (with uWSGI), and whether my reasoning of X processes + Y Python threads as explained above is on track?


Thanks.


--

.oO V Oo.

--
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.

Reply via email to