> 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