OK and what's new?

Evolution? Sorry, 30+ years in capacity and performance, so what's evolutionary here? When I started even the trainees did know that a performance problem can be anywhere in system and not just in one component. And after first case even learned that fixing "the" bottleneck often just creates performance problems in some other place or in some other application. After second incident the brighter ones realized that often the "root cause" is not a program, database, device, line, whatever but a bad (systems) design more often than bad code or faulty hardware.

Good article and needed! And so true - I just had all the possible troubles to find a performance problem in a state wide system. Not that the system was anything very complicated but fighting the customer which believed that the problem must be in network - one organization was suffering bad (terrible!) response times, others were mostly OK, so? It took time and pain to convince them that I have to look the whole system. After all, it turned to be a badly designed SQL query (or could be also fixed by database redesign) in a program which had nothing to do with that organization, it just caused their applications to slow down! A very common problem in 24x7 systems where a lot of reports are run all the time.

Or "real" network problems, network people may laugh but it took me a week to convince a remote customer just to try a simple fix, change a short cable! They insisted that the problem must be in program because that's how their network monitoring system analyzed it! Looking their logs and with some experience it did look to me at first sight either a controller or cable problem but because they were outside of the organizations functions they didn't even want to hear that?

Or trying to convince a product manager that one product has a bad design when the whole system throughput got worse instead of better when adding more processors. More time wasted arguing than redesigning and recoding the problem parts - actually over 10 fold throughput after that? That was an interesting but frustrating fight. Same, a long time ago, with moving database indexes to a faster device - have you ever tried to explain queuing theory to some managers? Or arguing that performance can not be managed by priority only - the same managers who think that an organization performance can be managed by just by prioritizing the work?

Or other thousands of performance problems I have seen over years from sleeping operators, fluctuating electricity in some circuits to miscoded monitoring system rules (sometimes not even connected to the system which has a problem)!

Performance as well capacity and security are business functions, not technology, so what and why is so difficult to understand? How many CEOs, COOs, CIOs. etc does the company have? Usually not too many and for a reason, I think. So, the article is correct, performance problems are real but often misunderstood because it is easier(?) to blame someone or just one part of the system than to look the whole picture.

Click to read the article this is in response to.