我们公司有三台专用服务器，一台运行 Nginx 并充当 Web 服务器（php），另一台处理 MySQL 和 Memcached，还有一台用于提供静态文件：css、js 和图像。
所有服务器在 New Relic 上都表现良好，特别是静态文件服务器：
- CPU 持续低于 10%
- 网络 IO 接收速度非常低，传输速度最高约为 10 Mb/s，但 MySQL 服务器具有相同的规格，并且通常以 20 mb/s 达到峰值，因此怀疑这不是一个问题。
- 平均负载低于 0.5
问题是，在高峰时段，这些图片（大小可能为 100kb - 200kb）显然需要很长时间才能让某些用户加载（需要很多秒，有时甚至长达一分钟，而通常在最坏的情况下只需几秒钟）。
知道我们能做什么吗？理想情况下，如果 CPU、RAM 或带宽都没有达到任何限制，这种情况就不会发生。
我们应该查看（并且可能更改）哪些关键的 Nginx 配置参数？
答案1
我能想到有两种可能性。
- 您的磁盘已达到其 I/O 上限。
- 您已达到 nginx 中的工作线程限制。查看工人_*来自核心模块的配置参数和worker_connections从事件模块中了解如何提高这个值。默认是单个工作进程，即单线程，因此如果您在多 CPU 平台上运行，那么您绝对应该提高这个值。即使您使用的是单 CPU 机器，在提供静态资源的机器上提高这个值也会让您受益匪浅，因为您将比其他任何事情都更早地受到磁盘 I/O 限制，而其他线程可以在第一个线程等待从磁盘输入数据时接收和处理更多请求。
答案2
我们可以坐在这里整天猜测您的瓶颈在哪里，但一些更一般的建议将帮助您更快地找到它。
jeffatrackaid 写道这个答案昨天这是更简洁的版本我很久以前写过。我建议先阅读这些内容以帮助理解如何进行性能调试。
对于您的情况，我会首先使用 Firebug 来确定高峰时段请求的哪部分变慢了。如果带宽不是真正的问题，这应该可以排除带宽问题。查看 Firebug 的“网络”部分，看看请求的哪部分在高峰时段和低谷时段之间发生了变化。
之后，我会在其中一次运行缓慢的 nginx 工作进程时，同时使用-t和选项运行 strace。分析该输出应该会向您展示 nginx 运行缓慢的确切位置。将 strace 输出写入文件，然后在文件上使用或来识别耗时较长的系统调用很有用。-Tlessgrep
-c您可能会发现strace 选项很有用。
确定了慢速系统调用后，仍需要做一些工作来找出需要更改哪个 nginx 参数，但您应该已经取得了成功。如果您需要这方面的帮助，请回来询问更具体的问题。
如果事实证明这是一个基于文件的系统调用，请务必回顾跟踪，直到找到它正在等待的文件。这将是一个很大的提示。