【发布时间】:2009-03-17 07:47:17
【问题描述】:
我对压力测试非常陌生,我只是在尝试学习其中的技巧。所以我的问题是:
如果我的开发服务器在软件方面是相同的,但在硬件方面的规格比生产服务器低得多,是否值得对开发服务器进行压力测试以识别明显的软件缺陷?
如何在不危及用户体验的情况下对实时生产服务器进行压力测试?或者应该避免对实时生产服务器进行压力测试。
【问题讨论】:
标签: stress-testing
我对压力测试非常陌生,我只是在尝试学习其中的技巧。所以我的问题是:
如果我的开发服务器在软件方面是相同的,但在硬件方面的规格比生产服务器低得多,是否值得对开发服务器进行压力测试以识别明显的软件缺陷?
如何在不危及用户体验的情况下对实时生产服务器进行压力测试?或者应该避免对实时生产服务器进行压力测试。
【问题讨论】:
标签: stress-testing
以下是各种提示/建议:
如果您的应用程序是新应用程序,因此您不知道它是否能够处理生产中的负载,那么您需要进行“容量”测试。您应该在生产硬件上进行容量测试,因为它还没有“上线”,所以不会影响用户。
如果您的应用程序是已经部署在生产环境中的现有应用程序,那么您应该做的是“性能回归”测试。
性能回归测试包括对开发服务器上的所有单个“功能”(无论这对您的应用程序意味着什么)进行压力测试,以测量其性能。您将结果记录作为您的“基线”。
当您对应用程序进行更改时,重新运行性能回归测试以查看是否有任何结果与基线相比发生了显着变化(并将新数字记录为新基线)。
李>如果您的开发服务器上的性能回归结果与基线相比没有太大变化,那么您应该可以安全地部署到生产环境,而不会改变服务器利用率(即过载)。
【讨论】:
我认为你应该避免任何工作,包括在生产机器上进行压力测试,除非你知道你有一个无法在你的测试环境中重现的问题——也就是说你可能知道你的用户不知道'晚上不使用系统吗?如果测试不是 intrusibe/read only,那么我会说这是一个额外的选项。
至于在weeker 机器上的分析性能,它并没有那么糟糕 - 大多数瓶颈是由系统的不良架构引起的,并且应该在不同的硬件配置上可见,只是在不同的负载场景下 - 可能更容易注意到周末机器上的问题,所以我会说对您的开发系统进行压力测试和优化,您会知道至少理论上您的生产系统应该更好。
【讨论】: