nginx 大型静态文件在 AWS EBS 支持的服务器上服务缓慢答案

【问题标题】：nginx large static file serving slow on AWS EBS-backed servernginx 大型静态文件在 AWS EBS 支持的服务器上服务缓慢
【发布时间】：2013-03-24 18:03:47
【问题描述】：

我正在尝试在完全由 EBS 支持的 AWS 服务器上找出正确的 nginx 调整。基本问题是，当下载约 100MB 的静态文件时，我看到的下载速率一致为约 60K/s。如果我使用 scp 从 AWS 服务器复制相同的文件，我看到的速率约为 1MB/s。（所以，我不确定 EBS 是否会在这里发挥作用）。

最初，我使用开箱即用的配置运行 nginx（对于 CentOS 6.x）。但是为了加快速度，我尝试了各种调整参数，但都无济于事——速度基本保持不变。

这是我目前配置中的相关片段：

location /download {
    root /var/www/yada/update;
    disable_symlinks off;
    autoindex  on;

    # Transfer tuning follows
    aio        on;
    directio   4m;
    output_buffers 1 128k;
}

最初，这些调整设置是：

sendfile       on;
tcp_nopush     on;
tcp_nodelay    on;

请注意，我并不是要针对大量流量进行优化。在任何给定时间可能只有一个客户端下载。 AWS 服务器是一个具有 617MB 内存的“微型”实例。无论如何，scp 可以以 ~1MB/s 的速度下载这一事实让我相信 HTTP 应该能够匹配或超过该吞吐量。

感谢任何帮助。

[更新] 附加信息。在下载运行时运行“顶部”命令，我得到：

top - 07:37:33 up 11 days,  1:56,  1 user,  load average: 0.00, 0.01, 0.05
Tasks:  63 total,   1 running,  62 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

和“iostat”显示：

Linux 3.2.38-5.48.amzn1.x86_64      04/03/2013  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.02    0.00    0.03    0.03    0.02   99.89

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
xvdap1            0.23         2.66         8.59    2544324    8224920

【问题讨论】：

你找到this similar question了吗？在 100% 的 CPU 下，它看起来确实很相似。
我做到了。但是我的 CPU 完全空闲。我现在设置了'sendfile off;' 'aio on;' '方向 256k;'我的吞吐量平均高达 ~130K/s。更好，但距离 1MB/秒还有很长的路要走。
先排除隐形爪牙。如果你在同一台机器上下载，首先通过 localhost 然后通过它的官方主机名，那么速度如何？
本地在同一台机器上，使用官方主机名，HTTP 的速度约为 15MB/s。

标签： nginx amazon-web-services centos

【解决方案1】：

您考虑过打开 sendfile 吗？ Sendfile 允许 nginx 直接使用内核发送静态文件，所以它应该比任何其他选项都快。

【讨论】：

【解决方案2】：

鉴于事情在您受到限制的同一台机器上运行良好。首先检查您与 AWS 的使用政策，也许它在细则中。或者，尝试不同的 ISP。如果它们都给你 60kB/s，你就知道是 AWS。

【讨论】：

【解决方案3】：

默认情况下 scp 会比你的 HTTP 连接快得多。我有一个建议给你。如果您提供静态文件，我更喜欢将 S3 与 Cloud front 一起使用。这使它更快。文件传输很难达到更好的性能。

【讨论】：

我不确定你在哪里假设 scp 会比 http 更快。事实上，默认情况下它会更慢，因为必须加密。