Pyramid, threads and uWSGI
Vlad K.
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.
Roberto De Ioris
>
> 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.
Python threads ARE mapped 1:1 to os threads. The GIL is only a pthread_mutex
governing object access (obviously, i am speaking about a pthread-based
implementation, that is the case for Linux/BSD/Solaris)
>
> 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...).
this is a good (and right) analysys
>
> 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.
if you do not intend to run multiple pyramid apps in the same process, you
can add --single-interpreter to gain a bit of memory (not performance)
>
> 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.
starting from uWSGI 1.0, the threading model is the same of mod_wsgi
(thanks to Graham Dumpleton help)
--
Roberto De Ioris
http://unbit.it
Vlad K.
Hi, thanks for your reply.
> Python threads ARE mapped 1:1 to os threads. The GIL is only a pthread_mutex
> governing object access (obviously, i am speaking about a pthread-based
> implementation, that is the case for Linux/BSD/Solaris)
My understanding was wrong then, but what you say makes sense.
> if you do not intend to run multiple pyramid apps in the same process, you
> can add --single-interpreter to gain a bit of memory (not performance)
Memory is exactly what I was concerned with. Am I correct when I say
that single process will consume all the memory required to import all
the used modules, but threads will all share those modules and only
consume as much additional RAM as required by thread-local data?
Thanks,
V
Roberto De Ioris
>
>
>s sense.
>
>
>> if you do not intend to run multiple pyramid apps in the same process,
>> you
>> can add --single-interpreter to gain a bit of memory (not performance)
>
> Memory is exactly what I was concerned with. Am I correct when I say
> that single process will consume all the memory required to import all
> the used modules, but threads will all share those modules and only
> consume as much additional RAM as required by thread-local data?
>
yes (more or less, there is additional memory, as stack that is allocated
for each thread, but it is very little).
Igor
> Hi all!
>
> I'm testdriving uwsgi to deploy Pyramid apps, and there's something I
> don't think I quite understand.
single uwsgi process, you should probably use uwsgi's 'Emperor Mode',
it launches multiple uwsgi processes for every python app.
http://projects.unbit.it/uwsgi/wiki/Emperor
Vlad K.
Yes, thanks, but I'm having only one application per process anyway.
V