SQL Performance - One counter to rule them all - identify CPU/MEM/DISK/NET pressure I've been performance tuning SQL servers for a few years as a DBA. 

I'm trying to create a fast-food version of performance metrics that can quickly (in 5 minutes) and accurately (provable) answer a question from Management "Does this server need more/faster _ ?"

'_' being one of these 4 possible bottelenecks in an IT-stack bottom up (from server-perspective, without going in to the app/code/ui):


NETWORK
DISK
MEMORY
CPU


There are thousands of counters, articles, products to help monitor these. But is there a simple, instant and accurate script that can pinpoint if any of these 4 need to be scaled up or scaled out ?

e.g.
sys.dm_os_wait_stats - SOS_SCHEDULER_YIELD has high signal waits => need either more or faster CPU.
PAGEIO_LATCH => need more files or faster DISK

Are these 2 accurate? Does Page Life Expectancy accurately 'PROVE' the need for more memory ? What is your GO-TO script for diagnosing a performance issue ?

I've used sp_whoisactive, sp_blitz, Glenn's DMVs, Spotlight, Idera etc. but am yet to come across a script that will satisfy a CIO's question about where to spend budget money, or that will correctly blame the problems on bad code, or slow SAN, or the ISP.  

Everytime any (Network/Systems/DBA/App) engineer points fingers at the other team, we have to 'PROVE' our statement, and with Virtualization and Cloud, without ideal test environments, without downtime, it's getting increasingly difficult to provably pinpoint the source of server performance issues, other than maybe Task Manager &lt;excuse the rant>
No. Say you have a server with:


High PAGEIOLATCH waits
High IO stall times
Low Page Life Expectancy (say, consistently under 30)
128GB RAM


You could fix this scenario with:


Index tuning - because maybe the queries are scanning a table too large to fit in memory
Query tuning - because maybe they're using non-sargable predicates, or not caching
Configuration - because maybe some wacko set max server memory too low, or we're using the wrong Cardinality Estimator for our code
Adding memory - but now you have to check version &amp; edition, because your Windows or SQL Server may not support more memory
Faster storage - but this is one heck of an expensive fix


There's no one metric that tells you which of those solutions is the right one. Welcome to performance tuning. Ain't no easy button here.