request_time
官方网站描述：
它是指从第一个字节接受用户请求到发送响应数据的时间的时间，即，包括接收请求数据时间，程序响应时间和输出响应数据时间。
upstream_response_time
官方网站描述：
它是指从NGINX到后端PHP-FPM开始接受数据然后关闭连接的时间。
从上面的描述可以看出，$ request_time必须大于$ upstream_response_time。尤其是在使用后模式传递参数时，由于nginx缓存了请求主体，因此收到后的数据将一起发送到后端。因此，如果用户网络很差或传输数据很大，则$请求$比$ upstream_response_time。
因此，如果您使用nginx的AccessLog查看PHP程序中的哪些接口速度很慢，请记住将$ upstream_response_time添加到log_format。
我们的情况是request_time相对较大，猜测可能是由以下问题引起的：
因此：较高的请求_time可能是由连接速度较慢的客户端引起的。High request_time不一定表示服务器和/或应用程序的性能。
分析时，您实际上不应该在请求_Time上花费太多时间，而应该测量应用程序的响应时间（即upstream_response_time）。
我们的架构相对特别。有两组项目，一个重建项目和一组旧项目。该请求将其转发到一个新项目。如果您返回404，然后将其转发到旧项目，因此我们Canupstream_Response_time具有2个值：
11.11.11.11:80是一个新项目。因为它返回404，所以响应时间为0.015
22.22.22.22：80是一个旧项目，因为处理时间太长，所以响应时间长，超过30秒
检查旧项目nginx_error.log
上述错误的两个主要原因：
1. PHP-FPM超时过程终止
2.不足以结束该过程
查看PHP-FPM配置
我们得出结论，Nginx告诉我们不要收到反馈，PHP-FPM告诉我们，该过程中断了
看看村民的访问。
UP_RESP_TIME超过30s，结合了我们的php-fpm.conf的配置，上面的错误上面的错误，肯定是执行时间太长
查看php-slow.log，发现要求外部接口太慢。
致电外部界面以增加超时，以避免占用PHP-FPM太久
少数响应时间的问题偶尔发生可能是由外部效应，网络异常等引起的。
当少量响应时间时间太长时，您可以检查以下方面以找到问题。
检查当时服务器日志中是否存在错误；
检查服务器资源的使用是否正常，负载平均值，CPU使用率（尤其是单个核心CPU）是否在飞涨；
检查磁盘是否具有高负载，例如Iostat Util％太高；
确认当时网络情况是否正常，以及是否存在网络数据包丢失和其他现象。
以上调查建议是根据全面监控进行的。将问题定位更加困难。拥有全面的监控数据进行调查要方便得多。
参考：https：//www.phpmianshi.com/？ID = 123
原始：https：//juejin.cn/post/70985965417947448