[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