poh*_*ohl 15 architecture optimization stress-testing performance-testing
我的组织现在正在进行一场有趣的内部辩论,提出了一个我想向社会开放的问题.
手头的问题是我们的环境,我们在其中进行压力测试,容量测试,性能回归测试等.
争论的一方面是一些软件工程师希望这种环境尽可能地反映生产环境,以使结果尽可能有意义.虽然我们目前确实有这样的测试环境,但它的能力远远低于生产系统,而且这些软件工程师认为他们正在达到他们可以从中学到的极限.
争论的另一方面是一些网络工程师,他们既管理环境又控制钱包.虽然他们承认在能够更好地复制生产环境的环境中容量测试会更好,但他们认为 - 为了压力测试的目的 - 更温和的环境会产生放大性能瓶颈的影响,使它们更容易发现并修复
这最终将我们带到引起我兴趣的部分:一位软件工程师建议,虽然一个更温和的压力环境会增加你遇到一些瓶颈的可能性,但它并不一定意味着它可以帮助你找到你可能遇到的下一个瓶颈在生产中遇到.他认为,缩放效应可能不是线性的.
那个观点是否有价值？如果是,那为什么呢？这种非线性的来源是什么？
这里涉及许多活动部分:一组Java应用程序服务器,一组数据库服务器,为每个HTTP命中生成大量动态内容.
编辑:到目前为止,我很欣赏每个人的想法,但我真的希望有人能做的不仅仅是重新确认一方或另一方并实际解决"为什么"的问题.如果存在这种非线性,会产生什么？更好的是,如果原因表现在CPU,内存,带宽,延迟,子系统之间的交互,你有什么...... TerryE,你来的最近.如果没有其他人加强,您应该重新发布您的评论作为赏金的答案
您的软件开发人员是对的,我会更进一步.
当您测试应用程序组件(如Web服务)以查看其在负载下的行为时,使用功能较弱的环境是可以理解的.你可以找到关于内存,io等的瓶颈.而且很可能会发现内存错误和日志文件变得越来越大的漏洞和疏忽.
但是当您的应用程序组件按预期运行并且您需要测试整个shebang时,您需要测试真实环境.
在环境中运行压力测试时,可以测量环境在负载下的行为及其瓶颈.虽然此测试可能提供有价值的信息,但此信息不会与您的生产系统有关.您找到的瓶颈可能与您的真实系统无关,您可能花费宝贵的开发时间来修复不存在的错误.要了解您可能面临的瓶颈,您应该在您的真实生产系统上进行压力测试(最好在盛大开幕之前).
网络工程师的假设是,适度的系统基本上是生产系统的比例模型.他们还假设生产环境的各种特性会影响软件性能,只是在较低的水平,但是在相同的比率下才会反映在更适度的系统中.例如,CPU不是那么快,没有那么多的内存,存储速度有点慢等等,并且所有这些差异都是相似的比例,这样如果一切都神奇地乘以某个因素,比如1.77,由此产生的改变后的适度系统将与生产系统完全相同.
然而,对于生产系统的所有细节而言,适度的系统是精确的比例模型,我很难相信.
这是一个具体的例子.可以说生产系统上的测量结果表明CPU利用率(CPU没有空闲的时间百分比)太高.因此,您将软件放在适度的系统上并进行测量,并发现在适度的系统上,CPU利用率较低.调查显示,适度的系统存储速度较慢,因此CPU花费更多的时间等待从存储到完成的数据传输,因为应用程序是I/O绑定在适当的系统上,而生产系统则不是.这种差异是由于适度的机器不是生产机器的精确比例模型,因为CPU比率不同于I/O传输比率.
另一个例子是拥有更多内存,允许生产环境中更少的页面错误.当软件加载到更适度的机器上时,由于物理内存较少,会出现更多页面错误.随着各种应用程序分页进出,它们开始相互影响,因为其他应用程序的页面被换出然后再次交换回来.在具有更大内存的产品计算机上,由于有足够的内存来同时容纳更多应用程序,因此无法看到此级联页面错误行为.
我在这里要做的一点是,具有各种部件和应用程序的计算机是一个复杂的动态系统.一个计算环境只是另一个计算环境的比例模型的想法过于简单化了.使用适度的系统当然可以提供有价值的数据.但是,一旦对软件进行了大量调整,并且您开始进行更细微的详细调整,环境的差异就会对测试结果产生很大影响.
一些引用. 计算机系统是 Tod Mytkowicz,Amer Diwan和Elizabeth Bradley的动力系统.
动态系统中的贝叶斯故障检测和诊断由Uri Lerner,Ronald Parr,Daphne Koller和Gautam Biswas负责.
我在生产环境中遇到过类似的情况.我们仅使用适度的系统进行初始和基本级别的测试和发现.确实,您永远无法在测试环境中找到真正的瓶颈和其他性能问题.因此,要找到真正的性能相关问题并找到瓶颈,您必须在生产环境中进行,没有其他办法.
我们已经托管了超过250万个网站,虽然它可能不是你的网站,但让我告诉你,在我们的例子中,我们遇到了线性瓶颈的可怕情况.意思是,当我们的流量增加时,我们首先遇到了内存问题.我们通过添加更多内存解决了这个问 在那之前我们甚至没有注意到只有256个httpd线程是我们的下一个瓶颈,因为有限的内存隐藏了它,一旦我们解决了内存问题,它很快就会解决为什么我们的网络服务器在几周后再次变慢的问题？我们发现256个httpd线程不足以为这么多流量提供服务.我们不仅增加了线程,还在WebServers前面安装了HA并行负载平衡器,以缓解此问题.
幸运的是,它解决了我们的慢页加载问题.但随着流量持续增长几个月,我们陷入了存储系统的下一个瓶颈.你知道这次磁盘I/O是什么问题.为了简化故事,我们提出了基于NFS的并行物理存储系统.每个NFS机器现在通过运行超过2000个线程来提供文件.
我忘了提到数据库也是一个缓慢的罪魁祸首,我们通过在集群中安装Master-Slaves模型解决了这个问题.我们还必须在应用程序代码中进行大量的性能调整,并且我们必须将应用程序物理地分布到不同服务器上的不同模块中.
我只是提到所有这些,以证明所有与性能相关的问题很可能几乎以线性方式出现,至少这是我们在WebBased模型中遇到的问题.即使您在适度的系统上进行了大量测试,您仍然有机会隐藏在测试环境中无法找到的瓶颈.
我在过去6年的经验中学到了如果您认为自己可能会有很多流量或点击/秒,那么尝试尽可能多地分发您的模型.集中模型可以通过做大量调整来保持您的流量一段时间,但最终您的系统被破坏了.
我并不是说你在你的情况下会遇到一些瓶颈或问题,但我只是想警告你,这些情况有时会发生,只是让你更清楚.
**对不起我的英语不好.