这是一个间歇性但非常现实的问题的一个小背景。 我维护一个在Esxi私有云上运行的Web应用程序。 我们有一个数据库服务器和4个Web应用程序服务器。 4个Web应用程序服务器都有一个很奇怪的问题。 服务器全部运行（Ubuntu 10.04.3,2.6.32-28-服务器，Apache Web服务器，proftp ftp）当我通过ftp或http（内部或外部）传输许多映像时，大部分时间是非常慢。 例如，下载一个大约400张图像（<2兆字节）的目录，传输速度非常慢，有时甚至完全停留。 同样在http上，如果我第一次在我的浏览器中加载我的页面之一，取决于有多less图片，它可能会有同样的困难。 当我再次加载相同的页面时，由于浏览器caching，这是可以的，但是一旦我清除了caching，它就回到非常慢的速度。 我说可能是因为这种情况一直没有发生，有时它以正常的速度传输文件，这几乎是瞬间的。 所有这些机器都是虚拟的，我试图重新构build它们，但没有成功。 有人提出这可能是一个主机名，或命名问题，但并没有真正提供这个理论麻烦的线索。 我不是服务员，也不是假装成一个人。 我们的服务器由托pipe托pipe的第三方托pipe，但托pipe托pipe似乎不知道如何处理这个问题。 任何帮助将不胜感激
你的目标是find瓶颈。 换句话说，pipe道中造成缓慢起伏的特定地方。
第一步是收集数据。 最常见的瓶颈是networkingIO，磁盘IO，CPU和内存约束。 您可以使用完整的监控系统来收集像Cacti这样的数据，或者像sar这样的本地资源，这是systat软件包的一部分。
获得这些数据后，您应该能够通过Web日志中的响应时间来交叉引用它，并查看是否有任何数据相关。 它可能不会，你将不得不深入挖掘 – 但这些作为你总是首先检查的重要因素。
不那么花哨，你可以只看vmstat输出，你可能会很幸运，并抓住问题 – 但间歇性的问题可能很难解决。
解决问题时，通常使用沿着stream水线的二进制search来尝试消除variables。
因此，例如，如果您正在从工作站上的浏览器进行testing，请从服务器本身运行testing以切断您的工作站和networking。 如果你不再有这个问题，那就是你的桌面或者你和服务器之间的networking。 如果你仍然有问题，它必须住在服务器的某个地方。
另外，如果这是一个dynamic网页，那么应用程序本身可能会出现问题，所以您也可以通过分析生产代码来解决这个问题。
最后，虚拟化环境的一个难题是其他的虚拟服务器可能会影响到你的 – 但是你可能不想跳到这个结论，直到你至less监视你的生命。
缓慢，无论是永久性还是间歇性，都可能是由于I / O争夺。 如果在同一台主机上有许多活动的虚拟机，那么您将与它们争夺I / O带宽。 也可能是主机在内存使用方面过度使用，所以分配给您的虚拟机的内存页面正在主动交换，效果差不多。
当通过HTTP传输很多小图像文件时，问题可能不是服务器。 如果你离机器有一段距离，那可能只是一个延迟问题。 如果你和服务器之间的时间间隔是100ms（你可以用一个基本的ping命令来检查这个），并且浏览器使用2个并发连接，那么你将看到每个图像大约50ms的平均值，仅仅是由于networking潜伏。
同样，对于通过FTP发送多个文件，尽pipeFTP协议非常琐碎（传输文件需要至less两次命令连接和打开一个新的数据连接），所以对延迟相关的性能问题比HTTP更敏感。 您可以使用SFTP或SCP（OpenSSH和其他SSH服务器提供的）更现代的协议来提高文件传输性能（ 不是 FTPS：这只是通过SSLstream的FTP，所以普通FTP的所有瓶颈加上SSL）。