xsevensinzx (4/29/2016)

---

Gary Varga (4/29/2016)

---

xsevensinzx (4/29/2016)

---

When I worked in the video game industry, we were building massively multiplayer online games. As you could imagine, in this scenario, you are playing an online game with a graphical rendering engine on the front end, but all the assets/data are stored in a database on the backend. Thus, stress testing how many players (users) are interacting with the product was critical. Everything you do in-game touches the database as well other underlying services. If you move two feet, pick up a item from the ground, send a message to a friend or whatever. It all taps the database. While you built it with a number in mind, you don't truly know until you schedule a official stress test, get about 1,000 users online and tell them to go crazy.

This is what I was referring to as performance testing and I believe that it is different from hardware stress testing. Of, course I have been known to be wrong. From time to time.

Not sure I see the difference outside of directly running tests on the hardware itself. In the scenario above, all the hardware behind the scenes is supporting those 1000 or so users. That's the stress they will have in a real-life scenario if we grow. Anything you do on the hardware itself is a simulation that does not represent the factual users.

I'm not saying it's not beneficial, especially if you can't get the amount of users to stress test for you, but it's still a stress test on the hardware in both cases.