2 ms·
Very good article, I think! Reveals many of the subtleties that are easy to get wrong. ---- > A common shortcut is to generate the load on the same machine (i
by kqr 4y ago
Very good article, I think! Reveals many of the subtleties that are easy to get wrong.
----
> A common shortcut is to generate the load on the same machine (i.e. the developer’s laptop), that the server is running on. What’s problematic about that? Generating load needs CPU/Memory/Network Traffic/IO and that will naturally skew your test results, as to what capacity your server can handle requests.
This fear is overplayed, I think. A lot of production software is slow enough that load generation will not be a significant CPU/memory/network load. By worrying about this people miss other things that they should worry about much more.
----
> Run the actual load test for 1-5 minutes. (great numbers, huh?)
This is another common problem: for many garbage collected platforms (and platforms with other types of occasional delayed work), 1–5 minutes is not enough to trigger the pathological behaviour you want to test for. Some systems need to be loaded for 4–6 hours or more to see the full spectrum of behaviour.
- drewcoo 4y ago> This fear is overplayed, I think. It can be difficult to separate the effects on the system from the loader and the server. I think if it's overplayed it's because it's trying to convince people to not make it hard. Even doing them both on the same box is valuable, though. Functional tests aren't going to catch concurrency issues but load testing however you want to do it just might.