我在nginx后面有五个tomcat实例。
有时候nginx upstream_response_time很大，超过1秒，而tomcat本地访问日志显示处理时间仅为50ms（我使用%D来记录处理时间）。
可能的原因是什么？如何解决？由于其他应用程序运行很快，因此网络似乎并不慢。
更新：
似乎nginx upstream_response_time = %D + 1 sec。
答案 0 :(得分：2)
我的观察假设是数据包丢失。对我来说，这似乎是最可能出现的问题，因为您说的是，当请求很多时，它就会发生。要对此进行测试，您可以监控流量，例如tcpdump或iftop。如果您使用的是Ubuntu，则可以使用
sudo apt-get install iftop
sudo iftop
还有许多其他network monitoring solutions in Linux，令人惊叹的Wireshark适用于所有操作系统。
软件包丢失的一个原因可能是冲突，如果您使用的是Linux，则可以使用
ifconfig [interface]进行检查：
me@mymahine:~$ ifconfig eth1
eth1 Link encap:Ethernet HWaddrf f:41:8d:ef:41:8d
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000 <-------------------------- check here ---
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Tomcat和Nginx是否在同一台物理（或虚拟）计算机上？
进一步阅读
答案 1 :(得分：1)
服务器通常将请求排队，直到有可用的线程来处理请求为止。 如果队列中有许多请求，但只有几个线程，则单个线程可能会相当快地处理该请求，但是如果添加时间，则该请求已排队，使用者会看到更长的时间。
请参阅：How to increase number of threads in tomcat thread pool?
Measuring the number of queued requests for tomcat
查看是否可以增加线程数或减少accept_count，但是请记住，可能还需要增加其他资源（如数据库连接）的数量。另外请记住，更多的线程可能意味着更多的资源竞争。
可能值得尝试为此更改参数。通常，访问日志还应该显示消息被队列和处理的时间，但是我不确定。