应用程序应该多久进行一次压力或负载测试？
是否有关于应用程序应多久进行一次压力或负载测试的规则？我通常在新版本投入生产之前、硬件发生变化或已知预期用户数量发生变化时执行此操作。
但今天有人问我，即使没有引入任何更改，这是否应该成为生产中的应用程序的标准做法。如果是这样，多久一次？
Is there a rule on how often an application should be stress or load tested? I normally do it before putting into production a new version, when the hardware changes or when the expected amount of users is known to change.
But today i'm asked if this should be a standard practice for an application that is in production even if no changes are introduced. If so, how often?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
这实际上取决于您希望如何满足公司的需求。就个人而言，我们每天都会对集成（测试）构建进行负载测试 - 就像构建发布一样。在构建运行大约 1a 后，我们也编写了脚本来进行负载测试。我们的目标是专门寻找性能上的构建变化。即使我们不对代码进行更改，对代码进行负载测试的服务器仍然会收到更新/补丁/修补程序/服务包/等。最坏的情况是，一旦实现自动化，它就会提供额外的历史数据。
我们正在走这条路（构建相对论），因为尝试在生产中复制我们的硬件环境成本高昂。如果我们看到关键性能监视器突然发生变化（或逐渐变化），我们可以研究当时引入了哪些变更集，并隔离对性能产生不利影响的潜在代码变更。
听起来，您正在针对复制生产的实验室进行测试？这是一种与我们不同的方法，因为我们假设大多数瓶颈都是由代码引起的，而不是直接依赖于硬件。我们使用虚拟机来近似但不复制我们的生产环境。
It really depends on how you want to address it for your company's needs. Personally, we load test our integration (test) builds daily - just like the builds go out. After the build runs at approx 1a, we have it scripted to be load tested as well. Our goal is specifically looking for build over build changes in performance. Even if we do not introduce changes into the code, the servers that the code is load tested on still recieves updates/patches/hot fixes/service packs/etc. At worst, once automated, it provides additional historical data.
We are going this route (build relativity) because it is cost prohibitive to try and replicate our hardware environment in production. In the event that we see a sudden change (or gradual changes) to key performance monitors, we can look into what changesets were introduced at that time and isolate potential code changes that adversely impacted performance.
From the sound of it, you are testing against a lab that replicates production? That is a different approach then we had, because we are going under the assumption that most of our bottlenecks would be code-induced and not directly dependent on hardware. We use VMs to approximate, but not duplicate, our production environment.
即使代码不变，影响系统性能的一件事就是数据。
一个例子可能是数据库查询的性能。当数据添加到表中时，维护索引的成本就会增加。索引中的页拆分会降低性能。随着索引的增长，索引中“级别”的数量经常需要增加。当这种情况发生时，你会看到性能发生突然的、明显无法解释的变化。
在生产环境中运行压力测试并不总是可行 - 它会影响您的日常业务。更常见的是，系统被用来提供有关性能的持续反馈。也许使用类似 ganglia 的东西。这些数据用于检测问题和进行容量规划。
One thing that affects system performance, even though the code is unchanged, is data.
An example might be performance of a database query. As data is added to a table the cost of maintaining indexes goes up. Page splits in the index can degrade performance. As indexes grow, the number of 'levels' in the index will every so often have to be increased. When that happens you see a sudden, apparently inexplicable change in performance.
Running stress tests in a production environment is not always possible - it affects your day-to-day business. More often systems are instrumented to provide on-going feedback about performance. Maybe using something like ganglia. The data are used to detect issues and for capacity planning.
我认为，每当您更改应用程序中的某些内容（代码、数据文件、用例）（包括但不限于预期的用户数量）时，您都应该对其进行测试。
I think that whenever you change something in the application - code, data files, use-cases - and that includes but is not limited to expected amount of users, you should test it.
我的两分钱：有时您不会更改任何内容，并且您的网站性能可能会受到影响。这可能是由于应用程序处理了太多数据（即：缓存溢出）。这可能是由于网站上的第三方广告速度减慢所致。哎呀，这可能是因为 RAM 故障！
最主要的是，虽然通常建议您在任何已知更改后进行测试，但偶尔进行性能测试以检查可能的未知更改也不是一个坏主意影响性能。
我的公司 BrowserMob 提供免费网站监控服务，每 X 分钟针对您的网站运行一次真正的 Selenium 脚本。虽然它不是负载测试，但它绝对可以帮助您识别生产站点中的趋势和瓶颈。
My two cents: sometimes you won't have changed anything and your site's performance could suffer. It could be from the app handling too much data (ie: caches overflowing). It could be from third party advertisements on the site slowing down. Heck, it could be because of fault RAM!
The main thing is that while it's generally advised you do testing after any known change, it's also not a bad idea to do occasional performance testing to check for possible unknown changes that could affect performance.
My company, BrowserMob, provides a free website monitoring service that runs real Selenium scripts every X minutes against your site. While it's not a load test, it definitely can help you identify trends and bottlenecks in your production site.
这取决于您的系统的任务关键程度……如果它只是一个一旦投入生产就可以不需要的小工具。如果你的生活依赖于它，那么在每一次构建之后。
就我而言，就是这样。
This depends on how mission-critical your system is ... if it is just a small tool that one can do without, once you put it on production. If your life depends on it, after every single build.
As far as I'm concerned, that is.
取决于测试需要多少努力。如果足够简单，更多的测试总是没有坏处的。然而，我认为没有理由测试是否没有预期的变化。如果这会导致软件很长一段时间没有经过测试，那么不时运行测试可能是合适的，以防出现意外的变化。
不用说，这还取决于您的软件运行的是核反应堆还是公告板。
Depends on how much effort the testing requires. If it is easy enough, more testing never hurts. However, I see no reason to test if there are no changes expected. If this would lead to the software not tested for a long time, then it might be appropriate to run the tests from time to time in case there are unexpected changes.
Needless to say, it also depends on whether your software is running a nuclear reactor or a bulletin board.
如果您的产品中没有引入任何更改，并且负载测试只是在一段时间内一遍又一遍地重复相同的过程，那么我看不到重新运行的好处。
If no changes are introduced in your product and the load testing simply repeats the same process over and over for some interval, I don't see the benefit of re-running.
我曾经将压力测试作为我的 ant 文件的一部分，所以如果我愿意的话，我可以每天晚上运行这些测试，并且当我进行任何更改或测试可能的新更改时，我会运行它们，这会以一种方式或其他影响我正在测试的内容，看看是否有任何改进。
我认为多久一次取决于您的环境。
如果您无法在开发中真正进行压力测试，那么您可能必须等到进入 QA，即在投入生产之前进行测试。
我认为你越早做越好，因为你可以更快地发现问题并修复它们，因为你知道它在两天前有效，昨晚它没有通过测试，所以白天有一些变化导致了它。
我使用 junitperf 进行了许多压力测试。
I used to have stress tests as part of my ant file, so I could run those tests every night, if I wanted, and I would run them when I was making any changes, or testing a possible new change, that would in one way or another impact what I was testing, to see if there was any improvement.
I think how often would depend on your environment.
If you can't really stress test in development then you may have to wait until you get to QA, where you are testing just before you go to production.
I think the sooner you do it the better, as you can find problems and fix them faster, since you know it worked two nights ago, last night it failed the test, so there was some change during the day that caused it.
I used junitperf for many of my stress tests.
我认为我们不想对记事本进行压力测试。这是一个笑话。没关系=）。
压力测试不适用于所有应用程序。 :-)
I think we don't want to stress test Notepad. It's a joke. Never mind =).
Stress testing not for all applications. :-)
如果你的软件可以杀死某人，我认为你应该这样做。
想象一下，有人因为系统超时而没有到达血液而死亡。
“超时.异常：你的心不再来了。稍后再试”
If your software can kill someone, i think you should.
Imagine someone dying because the blood didn't arrive because some timeout on the system.
"Timeout.exception: your heart are not coming anymore. Try again later"