> 2010/9/20 Roberto De Ioris <[email protected]>:
>>
>> It still could be an overload problem, we have no way (for now) to know
>> the time between
>> nginx connect() and uwsgi accept(). I do not know if the TCP_INFO
>> feature added to 0.9.7 could be useful.
>>
>> I will try to make a patch to let you test the status of connections in
>> real time (remember that only TCP mode is supported)
>
> I'm looking at your patch "the master process will signal the overload
> of the listen queue on linux tcp sockets":
>
> http://projects.unbit.it/hg/uwsgi/rev/b8fab39d08f9
>
> Is this what I should apply?  Also, I'm thinking it would be great to
> start using syslog, so that various priorities can be used, and the
> admin can sort and filter out important messages.  Direct output is
> not really usable.  I'm a bit scared by C code, but I should give a
> hand at this, I'm already familiar with the nginx syslog patch :-)
> --
> Jean-Baptiste Quenot
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>


On the nginx list Maxim pointed me to this logging variable:

$upstream_response_time


I have added it to my conf:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"
$upstream_response_time';


It works perfectly as it start the counter before nginx connect().

So add it to your stack and report to the list all the nginx log lines
relative to empty response

-- 
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to