[uWSGI] Versions and benchmarks and other problems

Roberto De Ioris roberto at unbit.it
Tue Jul 6 17:36:10 CEST 2010


Il giorno 06/lug/2010, alle ore 17.21, Paul van der Linden ha scritto:

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


4 prefork, means 4 concurrent requests against the thousand of nginx (yes it is a really beast, and i have seen
often cherokee do even more concurrent requests...)

> 
> 
> 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 []


you are right, nothing particular here

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

they are loaded the first time (for each worker) then they will be reloaded if a worker crashes. But after you have described your configuration
with 4 apache workers i am pratically sure that nginx as showed is muscles with your system :)

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



Damn, i always forget about those log-storm :) grep stderr (case insensitive) with "damn" ,"timeout" and "oops"
--
Roberto De Ioris
http://unbit.it
JID: roberto at jabber.unbit.it



More information about the uWSGI mailing list