Performance-Based Decisions: Deciding When and What to Test. Part I
Performance is such aspect that all users clarify as urgent to a satisfying adventure with software product. A little performance trouble existing on the user's customer machine is just that-an isolated little trouble on the customer machine.
Nevertheless, a very little trouble on a server will be enlarged many of times into a serious trouble affecting every user of the system. If a function call on the server is some megacycles rather costly, and every user operation calls that function, then those few additional megacycles need to be multiplied by the quantity of times it gets called to see the true cost. A little memory leakage on the server ultimately snowballs into a greatly serious trouble.
Nevertheless, there are trade-offs that can be made here. A little more cost on the client side, forcing the client to process information, may relieve the server of some functions, but it could eventually be a much dilatory experience for the client. The reason is that more bytes have to be pushed down the wire. Performance tuning is an exercise in making trade-offs.
The better the decisions made for the trade-offs - the better the performance. But even well decisions cannot completely recompense for bad architecture or some other troubles in the basis of software product. The target of performance testing is to find troubles and get them fixed.