是否有关于应用程序应该多久进行一次压力或负载测试的规则?我通常在将新版本投入生产之前、硬件发生变化或已知预期用户数量发生变化时这样做。
但是今天有人问我,即使没有引入任何更改,这是否应该成为生产中的应用程序的标准做法。如果有,多久一次?
是否有关于应用程序应该多久进行一次压力或负载测试的规则?我通常在将新版本投入生产之前、硬件发生变化或已知预期用户数量发生变化时这样做。
但是今天有人问我,即使没有引入任何更改,这是否应该成为生产中的应用程序的标准做法。如果有,多久一次?
这实际上取决于您希望如何满足公司的需求。就个人而言,我们每天加载测试我们的集成(测试)构建 - 就像构建出来一样。在构建运行在大约 1a 之后,我们将其编写脚本以进行负载测试。我们的目标是专门寻找性能上的构建变化。即使我们不对代码进行更改,对代码进行负载测试的服务器仍会收到更新/补丁/热修复/服务包/等。在最坏的情况下,一旦自动化,它会提供额外的历史数据。
我们正在走这条路(建立相对论),因为在生产中尝试复制我们的硬件环境成本高昂。如果我们看到关键性能监视器发生突然变化(或逐渐变化),我们可以查看当时引入了哪些变更集,并隔离对性能产生不利影响的潜在代码变更。
从它的声音来看,您正在对一个复制生产的实验室进行测试?那是一种与我们不同的方法,因为我们假设我们的大部分瓶颈都是由代码引起的,而不是直接依赖于硬件。我们使用虚拟机来近似但不复制我们的生产环境。
即使代码没有改变,影响系统性能的一件事是数据。
一个例子可能是数据库查询的性能。随着数据被添加到表中,维护索引的成本会上升。索引中的页面拆分会降低性能。随着索引的增长,索引中的“级别”数量将不时增加。当这种情况发生时,您会看到性能突然出现明显莫名其妙的变化。
在生产环境中运行压力测试并不总是可行的——它会影响您的日常业务。更常见的是,系统被检测为提供有关性能的持续反馈。也许使用类似ganglia的东西。这些数据用于检测问题和进行容量规划。
我认为,每当您更改应用程序中的某些内容时——代码、数据文件、用例——包括但不限于预期的用户数量,你都应该对其进行测试。
我的两分钱:有时你不会改变任何东西,你的网站的性能可能会受到影响。它可能来自处理过多数据的应用程序(即:缓存溢出)。可能是由于网站上的第三方广告变慢了。哎呀,这可能是因为内存故障!
主要的是,虽然通常建议您在任何已知更改后进行测试,但偶尔进行性能测试以检查可能影响性能的未知更改也不是一个坏主意。
我的公司 BrowserMob 提供免费的网站监控服务,每 X 分钟对您的网站运行一次真正的 Selenium 脚本。虽然它不是负载测试,但它绝对可以帮助您识别生产站点中的趋势和瓶颈。
这取决于您的系统对任务的关键程度......如果它只是一个可以不用的小工具,一旦您将其投入生产。如果您的生活依赖于它,那么在每次构建之后。
就我而言,就是这样。
取决于测试需要多少努力。如果它足够简单,那么更多的测试永远不会受到伤害。但是,我认为没有理由测试是否没有预期的变化。如果这会导致软件长时间未测试,那么不时运行测试可能是合适的,以防出现意外更改。
不用说,这还取决于您的软件是在运行核反应堆还是公告板。
如果您的产品中没有引入任何更改,并且负载测试只是在一段时间内一遍又一遍地重复相同的过程,那么我看不到重新运行的好处。
我曾经将压力测试作为我的 ant 文件的一部分,所以如果我愿意,我可以每晚运行这些测试,并且当我进行任何更改或测试可能的新更改时,我会运行它们,以一种方式或其他影响我正在测试的东西,看看是否有任何改进。
我认为多久取决于您的环境。
如果您不能在开发中进行真正的压力测试,那么您可能必须等到进行质量检查,在您投入生产之前进行测试。
我认为你越早做越好,因为你可以更快地发现问题并解决它们,因为你知道它在两个晚上前工作,昨晚它没有通过测试,所以白天有一些变化导致它。
我在许多压力测试中都使用了 junitperf。
我认为我们不想对记事本进行压力测试。这是个笑话。没关系=)。
压力测试并非适用于所有应用程序。:-)
如果您的软件可以杀死某人,我认为您应该这样做。
想象一下有人因为系统超时导致血液没有到达而死亡。
“超时。异常:你的心脏不再来了。稍后再试”