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