小编Gre*_*reg的帖子

我是 CDN 的新手，正在尝试 CloudFront。我已经设置了一切，一切似乎都运行良好。我可以在页面上创建静态图像并通过我的 CloudFront 分配访问它。我使用的是自定义来源（即不是 s3 存储桶）。

不过，我担心从性能的角度来看，我的情况可能会更糟。我有一个测试页面，它在使用和不使用 CDN 的情况下加载相同的 20 个左右的图像。查看 Firebug 中的网络面板，我第一次加载此页面时，直接从源服务器加载的图像的速度要快得多。在后续页面加载时，CDN 的好处变得显而易见——在 3-5 次刷新后，CDN 的表现比原始服务器好。

所以我可以看到，在我们网站上一个一直被点击的热门页面上，这将是一个好处。我应该期待一个好处，因为我在西雅图（在亚马逊附近）并且我的服务器在加州。

问题是，如果我离开页面几分钟然后重新加载，事情又会回到原点，CloudFront 比原始服务器更糟糕。这是预期的吗？东西会这么快地从 CDN“缓存”中掉出来吗？

我的设置中是否有可能影响性能？或者 CDN 只会对当前平均每隔几秒访问一次的内容产生净正面影响？

（从 AWS 论坛交叉发布，因为我一直被 SO 的周转时间宠坏了）

更新：

如果您对 CloudFront 性能有疑问，下面有两个很好的答案值得一看。我最近发现没有提到我的具体问题的一种解释。作为疏忽，我在 5 分钟时离开了 TTL。由于我也在使用自定义源，因此需要额外往返权威名称服务器以将其解析为实际的 Amazon CloudFront 域。现在 TTL 设置又回到了 12 小时，长负载似乎很少发生。

我有一台运行自定义 Wordpress+bbPress 组合的 LAMP 服务器（基于 CentOS 的 MediaTemple (DV) Extreme，具有 2GB RAM）。

每天大约有 30k 的浏览量，服务器开始抱怨。今天早些时候，当车流涌入时，它绊倒了大约 5 分钟。即使在正常情况下，我也可以看到虚拟服务器有时处于 90% 以上的 CPU 负载。使用 Top 我经常可以看到 5-7 个 httpd 进程，每个进程都使用 15-30%（有时甚至 50%）的 CPU。

在我们进行大的优化之前（我们使用 MySQL 可能是罪魁祸首），我很想找到主要违规的页面并首先处理它们。有什么方法可以找出哪些特定请求对 CPU 消耗最大的 httpd 进程负责？我发现了很多关于优化的一般信息，但没有找到关于这个特定问题的信息。

其次，我知道有一百万个变量，但是如果您对我们是否应该使用具有这种规模的站点的单个专用虚拟服务器处于性能边界有任何见解，那么我很想听听您的意见。我们应该考虑迁移到更强大的服务器，还是应该专注于优化当前服务器？