I thought '--threads' runs one python interpreters in each thread(e.x Linux
pthread), so I had the question.
>From your reply I learn that '--threads' option actually takes advantages of
>python thread, and
it dispatchs requests to function 'application' which is running in a python
thread.
I see now.
thx
------------------
Sincerely yours
ZHOU Xiaobo
------------------ Original ------------------
From: "Roberto De Ioris"<[email protected]>;
Date: Sun, Jan 8, 2012 03:03 AM
To: "uWSGI developers and users list"<[email protected]>;
Subject: Re: [uWSGI] the option '-thread'
> What is the difference between:
> uwsgi --processes 10 --threads 1
> uwsgi --processes 1 --threads 10 ?
>
>
> I mean is there any difference in the python interpreter's behavior? such
> as
> the global variables.
Threads share the process memory (address space), while each process live
in an isolated (more or less) memory area.
In python-world threads SHOULD be slower than multiprocessing as a global
lock (the GIL) forbid multiple threads to access python objects
concurrently.
In SMP systems this is overkill.
Honestly i do not care too much of the GIL, threads (for me) are a way to
increase concurrency, not performance, so if i want to manage 40
concurrent (blocking) requests on a 4 CPU system i would go with
--processes 4 --threads 10
this will mititgate the GIL impact (each process can run concurrently) but
will give me a concurrency factor of 40 with less memory than --processes
40.
Obviously the whole app (and it modules) must be thread safe... and this
is not always the case.
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
<br>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
