这里有一个间歇性但非常现实的问题的背景知识。我维护一个在 Esxi 私有云上运行的 Web 应用程序。我们有一个数据库服务器和 4 个 Web 应用程序服务器。这 4 个 Web 应用程序服务器都有一个非常奇怪的问题。这些服务器都运行（Ubuntu 10.04.3、2.6.32-28-server、Apache Web 服务器、proftp ftp）当我通过 ftp 或 http（内部或外部）传输许多图像时，大多数时候速度都非常慢。例如，下载大约 400 个图像（<2 兆字节）的目录时，传输速度非常慢，有时甚至完全停滞。同样，如果我第一次通过 http 在浏览器中加载我的某个页面，则根据图像数量，可能会遇到同样的困难。当我再次加载同一页面时，由于浏览器缓存，一切都正常，但是一旦我清除缓存，速度就会恢复到非常缓慢的速度。我说可能，因为这种情况并不是一直发生，有时它会以正常速度传输文件，几乎是即时的。所有这些机器都是虚拟的，我曾尝试重新构建它们，但没有成功。有人建议这可能是主机名或命名问题，但并没有真正给出解决这一理论的线索。我不是服务器专家，也不会假装是。我们的服务器由第三方托管，但托管似乎不知道如何处理这个问题。任何帮助都将不胜感激
答案1
您的目标是找到瓶颈。换句话说，就是管道中导致速度变慢的特定位置。
收集您的生命体征
第一步是收集数据。最常见的瓶颈是网络 IO、磁盘 IO、CPU 和内存限制。您可以使用像 Cacti 这样的功能齐全的监控系统来收集数据，也可以使用sarsystat 包中的本地监控系统。
获得这些数据后，您应该能够将其与 Web 日志中的响应时间进行交叉引用，看看这些数据是否有关联。可能没有，您必须深入挖掘——但这些是您始终首先检查的重要因素。
不那么花哨的是，您只需观察vmstat输出之类的东西，您可能会很幸运地发现问题 - 但间歇性问题可能很难解决。
定位问题是一项基本的故障排除技能
在解决问题时，通常使用某种沿管道进行的二分搜索来尝试消除变量是有意义的。
例如，如果您正在工作站上的浏览器上进行测试，请从服务器本身运行测试以切断您的工作站和网络。如果您不再遇到该问题，则可能是您的桌面或您与服务器之间的网络出了问题。如果问题仍然存在，则问题一定出在服务器的某个地方。
其他值得关注的地方
此外，如果这是一个动态网页，则应用程序本身可能存在问题，因此您也可以通过分析生产代码来解决这个问题。
最后，虚拟化环境的困难之一是其他虚拟服务器可能会影响您的服务器 - 但在您至少监控您的生命体征之前，您可能不想急于得出这个结论。
答案2
无论是永久性的还是间歇性的缓慢，都可能只是由于 I/O 争用。如果同一台主机上有许多活动虚拟机，您将与它们竞争 I/O 带宽。也可能是主机在内存使用方面过度承诺，因此分配给虚拟机的内存页面正在积极交换，这会产生大致相同的效果，但更糟糕。
但是，当通过 HTTP 传输许多小图像文件时，问题可能不在于服务器。如果您距离机器有一段距离，则可能只是延迟问题。如果您与服务器之间有 100 毫秒（您可以使用基本命令检查这一点ping）并且浏览器使用 2 个并发连接，那么您将看到由于网络延迟，平均每张图片的页面加载时间增加了约 50 毫秒。
同样，对于通过 FTP 发送许多文件，尽管 FTP 协议非常繁琐（传输文件至少需要在命令连接和打开新数据连接上进行两次往返），因此对与延迟相关的性能问题比 HTTP 更敏感。您可以使用更现代的协议（如 SFTP 或 SCP，均由 OpenSSH 和其他 SSH 服务器提供）来提高文件传输性能（不是FTPS：这只是通过 SSL 流的 FTP，因此具有普通 FTP 的所有瓶颈以及 SSL 的瓶颈。