2011/9/18 Roberto De Ioris <[email protected]>:
>
>> Hello.
>> I wonder - how async mode is implemented in uWSGI
>> it uses separate python interpreter for each async thread?
>> or is it withing one python interpreter?
>
>
> hi, multiple interpreters are used only to host multiple apps in the same
> process. In async mode each process can accept (and manage) multiple
> requests concurrently interrupting them (with yield or with some form of
> co-routine). Hosting multiple apps in async mode is possibile but you have
> to disable multiple interpreters (-i option)
>
I will use uWSGI to host a single high load app. (with alot of
incoming requests.. maybe some of them will be tough and take more
time.. so am thinking about async.)
I don`t understand what you wrote. First you saying that it is only
possible to host multiple apps using multiple interpreters. then in
the last sentence - that i must disable multiple interpreters.
Anyway - if i would use global module level vars like for example:
------ my_module.py ----
some_global_state_var = 1
--- my_app_.py ----
import my_module
def application(...):
my_module.some_global_state_var = value
....
# code using some_global_state_var here
----------------------------
I think this will break with concurrently incoming connections in a
single interpreter.
I am just asking of how to write my application.
>>
>> if my app use module level variables with async mode will it be messed
>> by context switch?
>
> all of the object in the process/interpreter are shared by all requests.
> Each request set the uwsgi.core variable to allows you to store
> request-specific object storing them somewhere and referring to them with
> this value
>
> For example:
>
> my_request_vars[env['uwsgi.core']] = 'foo'
>
hmm... i can understand you design of passing through env dict
env['uwsgi.core'] and env['.. timeout'] but construction
request[env['uwsgi.core']].something
does`t look elegant. I think this is mutch like a threadlocals.
The thing that bothers me - i will use lxml and maybe 1-2 other 3rd
parity libs (zlib for example) and how it will work out with async
mode inside signle interpreter.. hmm.. Can i use separate interpreters
for each async thread ? (i understand that this is memory waste but..
this is much more safe)
Also a few days ago i saw a real specification at
http://wsgi.org/wsgi/Specifications/fdevent
and now a page redirect or gives 404.
>>
>> How cheap is context switch using "yield '' " ?
>
>
> pratically nothing relevant
>
>> what if started with --async=20 .. and currenly thereis only 1
>> request from user
>> and i am doing context switch with yield '' - what will be a overhead
>> of doing so?
>
>
> if you want something really accurrate, sadly there are no many way to
> measure it, but if you call yield and there are no other requests it will
> simply iterate the response.
>
>>
>> Is it a bad idea to do context switch in a IO loop of application ?
>>
>
> i am sure yielding/suspending waiting for I/O is the best choice.
> Yielding/suspending for only splitting response is not so good as one may
> think.
>
> Remember that writing async apps with only python generators (read: yield)
> is not an easy task. Most of the time you would want to add a co-routine
> subsystem (like uGreen, greenlet or stackless python, all easy swappable
> via uwsgi.suspend() call) or more high-level platform like gevent or
> eventlet (eventlet uwsgi-plugin is still under-development).
Well stackless is not a option obviously.
Eventlet - well it is on top of libevent and thus have some limitations.
Gevent - is moving to libev and think old code (on libevent) is gonna be leaved.
Here http://blog.gevent.org/ Denis write about moving to libev and
bugs in libevent.
Also the stability of both projects seems unclear for me as i cant
find any big production companies using it.
(i also checked a bit gevent alpha and it did showed really strage and
slow results on gethostbyname example 6 seconds vs 0.2 of stable
gevent. Denis said something about c-ares but on other tasks 1.0 alpha
was also slower.. it just show me that it is too raw for production. )
I think my best choice is uGreen :) (it is ok that it is low level)
but i cant find a good examples of using it. only a tiny iobound_async.py
although uwsgi.wait_fd_write(c, 2) looks a litle bit odd after
standard poll stuff.
and i will have about 5-20 descriptors but i think the performance
should be ok as long as wait_fd_write is a C call.
(prohably i will write a cython loop over map of fd`s)
btw: if i registered 10 descriptors for write and 10 for read.. and then uwsgi
says yay there is event on fd5 .. should i again reregister fd? or
registration is persistent?
timeout parameter - individual for each fd?
i think uwsgi.async_connect,uwsgi.is_connected, uwsgi.recv - undocumented.
how does uwsgi.send behaves? switches context if would block until all
data is written?
should i intercept ordinary socket errors on uwsgi.send?
Maybe you can provide a little bit more complex example using more
than 1 socket and registering its with wait_fd_read/write in a loop?
And also - is it possible to create a new async thread for every
incoming connection instead of statically
setting max number at start? or it is a limitation of posix
makecontext family calls?
> the uWSGI async api is obviously faster, but it is very low-level, for
> tiny apps it should be very good, otherwise i suggest you to implement an
> abstraction on top of it or use the uwsgi-gevent plugin (it supports
> pratically all of the uWSGI features except for multithreading)
Thank you again for cool and fast server :)
> --
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
--
--------------------------------------------
Турнаев Евгений Викторович
+7 906 875 09 43
--------------------------------------------
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
