记录导致nginx的PHP-FPM超时的确切原因/代码块

Question

我已经用nginx设置了PHP-FPM，以获得一个相当广泛的API。每件事都像魅力一样工作，直到它不起作用。

2015/12/21 12:34:43 [error] 14113#0: *60938148 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 1.39.8.13, server: api.hlapp.com, request: "POST /v2/hlapp/get-fun HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "api.hlapp.com"

问题是，我无法准确地指出代码段的超时位置。API调用与网络上的其他几个事物通信，其中任何一个事物的故障或延迟都可能导致超时。诊断此问题的最佳方法是什么？我们是否可以有更详细的失败日志记录，就像Java中的那样？

另外，我必须补充的是，我已经做了所有类型的事情，比如分析代码等，但与微型组件连接的失败是不稳定的，并且不会在通常的分析中被捕获。它主要发生在生产环境中。

所以，总而言之，我要找的是一个更冗长的堆栈跟踪，它准确地告诉我代码在哪里超时。

Answer 1

经过多次的努力，我确实想出了一个解决方案。这是受Java编程范例的启发，几乎每个实现良好的延迟生成端点要么是可抛出的，要么是调用可抛出的，并且每个已知的异常都被捕获和处理。

因此，最好的解决方案可能是这样的。对于每个请求，确定通信通道，无论是数据库查询、辅助应用程序接口响应，还是任何其他可能导致PHP达到其max_execution_timeout限制的事情，将其包围在try catch中，将它们设置为一个时间限制，在此之后它们将“超时”。这逐渐有助于查明超时的原因(在我的情况下，Redis是无法访问的，因此我将Redis连接器对象的限制设置为5秒)。

希望这对某些人有帮助。