在 2014年11月12日星期三UTC+8上午4时16分54秒，agentzh写道：
Hello!
2014-11-11 1:41 GMT-08:00 z.s. jiang:
>
> 这个请求响应时间,有点离谱,但是testgetvoice 确实本身容易堵住了. 导致假死.
>
有非常多可能的原因（比如你使用的 nginx 核心或者 nginx C 模块中的 bug）会导致请求挂起，而你几乎没有什么什么具体信息，所以无法判断 :)
Regards,
-agentzh
感谢大牛回复帖子，问题貌似已经解决
业务场景为：
1） nginx+lua，提供业务模块功能 （web api ）
2） 接收到请求之后，需要调用外部资源（http），使用C写的模块请求。
3） 收到对方应答之后，对方未主动关闭， 使用strace -p work进程ID的时候，明显能看见read的时候，在等待超时才会断开。
是大量C模块无法快速处理，导致work hang 住， 表面现象是 $request_time 异常,
解决方法：
1） 万一对方server出现问题，则使用设置socket的timeout，
2） 对方server正常，主动关闭，则不需要主动关闭操作 （之前一直都是这种情况）
3） 对方server正常，但发送完数据未主动关闭， 则分析reqponse的http header，寻找content lengt的大小，与socket接收的总字节数比较，接收完毕了，则主动关闭，
优化了之后，使用 strace -p work 进程ID, 看到read完之后，立即close socket。nginx的work不会hang住。
调用外部资源有点害怕，动不动就hang住报警。
