[uWSGI] Versions and benchmarks and other problems

Paul van der Linden mail at paultjuh.org
Tue Jul 6 17:21:55 CEST 2010


On 6-7-2010 17:02, Roberto De Ioris wrote:
> Hi Paul, before doing benchmarks of such different solutions, you should
> clearly understand the different technics, or you will obtain pratically useless data.
>
> For example, mod_wsgi in embedded mode will use all the available apache processes/workers while
> uWSGI will continue to use only the number you have set). So you are testing an environment with hundreds of workers available
> with another with only 4 workers :)
>
> Onestly i do not know if mod_wsgi embedded is slower than uWSGI, i have stop doing this kind of tests after 0.9.2 :P
>    
I was aware of that, that's why I've limited the workers of apache to 4 
workers(pre-fork) too (forgot too mention that), but not only that, it 
was generating much more cpu usage then apache. But probably the cpu is 
completly generated by the problem mentioned below that.
> The second problem is probably spawned by nginx that has a bigger (really bigger) throutput than uWSGI (and apache obviously).
>
> If you attach a strace to the uWSGI processes (just after ab ends)  you can send it to the list, and we  eventually find a bug or a confirmation about
> overload made by nginx.
>    
I will try that tomorrow. Just setup apache again, so I could continue 
my own project.
> Then post your python code and the full command line to allow other users to rebuild your situation and make tests or suggestions.
>    
I will do that tomorrow too, when the problem still exists. The python 
code is not very difficult so that won't give any problems (Actually 
I've not implemented the check because I missed some information about 
the client which I will start implementing soon (on Android). The WSGI 
is reduced to this for now (only to simulate that the request is putted 
through python, most work is done once a day by a worker without wsgi):
from lxml import etree
from StringIO import StringIO

def application(environ, start_response):
#  some lines commented out code.
     start_response('200 OK', [('Content-type', 'text/xml;charset=utf-8'),
                                       ('X-Accel-Redirect', 
'/v1protected/%s' % environ['PATH_INFO'][1:])])
     return []
> Other Notes:
>
> - Dynamic apps are loaded on demand, so you will lose a huge amount (multiplied for the number of processes) of time waiting for them to be ready. Use
> static app and single interpreter mode for useful benchmarks.
>    
Is it actually loading everytime there is a request? I thought it was 
only loaded the first time it was requested, and when a worker is 
respawned. If this is the case, it will explain a lot of the extra load.
> - Always run the first benchmark with logging enabled, most of the time uWSGI will warn you of overload.
> When you reach  a no-error point, you can re-run with logging disabled or redirected to another server via udp.
>    
I've done that, I don't know how a message like that looks like? This 
will help me look for it in all those lines.

Greetings,
Paul


More information about the uWSGI mailing list