携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第1天，点击查看活动详情
在web开发的过程中，把web作为一个黑盒子，只掌握本身拥有的单一技术栈。“一招”打天下可能并不太现实。
内存不够了怎么办？加设备。
CPU不够了怎么办？加设备。
带宽不够了怎么办？加设备。
如果去面试某一岗位的时候，面试官问这三个问题的时候，真的可以好不胆怯的说出三次"加设备"，这三个字吗？
拿一个实际的工作中的例子来佐证这个问题吧。
最近几天，web程序在服务器上原本跑得挺欢快的，可是突然来了一群不速之客。平均每天访问量在7万次左右。如果粗略计算的情况下，也就是 7万/24/60，也就是每分钟在50次上下浮动。
如果web应用连每分钟50次的访问都扛不住的情况下，那还能在生产环境运行吗。在这种情况下，如果仍旧去给它加设备，也许这不太合理。
因为这种情况，如果只有两个用户，一个常规用户，一个数据采集的爬虫工程师，两个人对服务访问的话。很显然，很容易就会被爬死。同时，另一个正常用户就无法使用。
像上面这个问题，在工作中遇到了，像之前介绍的可以用visual studio中的性能探查器去看cpu的指标，查看消耗cpu的占比，通过内存的指标捕捉占用堆内存的较多的对象，或者是用debugdiag去分析dump文件。
结果可能发现，最终出现的问题并不是业务上的设计不合理导致的，而是连接数据库数据连接持续增长导致访问队列堵死后内存溢出。
所以这里要说明的几个问题是：
①加设备并不是万能的
②深入理解操作系统即便不认为它很重要，但一定是必要的
③学会看性能计数器
④掌握debugdiag的用法
性能计数器怎么看？大概的步骤如下：
从右向左滚动，垂直竖线是当前时刻，向右推进覆盖右侧的历史。如果这个不明白的话，那这个图直接就没法看。
性能计数器，对应计数器的含义直接在显示描述下就能够明确具体内容，如下：
会看图会选择计数器了，这两项基本技能具备以后，就需要根据两种现象的结果去判定当前计算机的状态。
windows性能计数器相当于一个接口层，它用于收集计算机的系统数据，比如CPU、内存、磁盘、I/O、进程、处理器等等。
用户通过性能计数器来观察了解对应系统的性能、行为。我们甚至可以根据自己的需求封装定义符合我们自己业务需求的性能计数器。
debugdiag怎么用？
这里再次用到了上一篇文章 监控应用的行为是找到性能问题的重要一步 中提到的关于Total CPU这一指标含义搜索的方式，来搜索debugdiag的工具。因为可能有一部分同学没有听过、用过这个工具。百度搜索inurl:docs.microsoft.com debugdiag，如下：
这个需要注意的是，可能会存在这样的问题，下载安装Update 2版本的时候可能会提示安装新的Update3.2版本，自动提示如下的地址，如果不提示的情况下，可以参考图片后附上的来源。如下：
对应的DebugDiag的一些指标和使用方法如下：
其中需要注意的是，在探测内存泄露的时候，需要注入LeakTrace.dll，如果没有注入的情况下，在生成的报告中会提示，因为没有注入LeakTrace.dll而无法记录。注入LeakTrace.dll的方法就是，在Process下对应进程的右键属性中选择 Monitor For Leaks，如下：
对于web应用程序，监控进程w3wp.exe进程，选择Monitor For Leaks后选择Create Userdump Series,因为采集的样本较少的情况下，可能对于有些现象无法分析出来，所以使用 这一项在某一个时间段内，持续收集dump数据。
然后使用DebugDiag 2 Analysis对采集的dump文件进行分析。如下图：
添加dump文件后，选择对应的Rule Name，点击开始分析。最终得到分析的结果报告。大概的样子如下：
可以找到对应的分析内容，比如关于内存泄露的如下：
选择对应的分配数量多的模块，点击查看详细的信息介绍，如下：
上面简单介绍了性能计数器查看系统当前性能指标，以及使用DebugDiag查看内存泄露的方式。
包括在开始处提到的“加设备”这种方式的提出。从常规的工作经验来看，不论是贸然加设备，还是凭感觉去找性能优化点，都是不够客观的。我们在程序问题处理，或者对性能问题进行定位和解决过程，应该尽可能的明确对应的性能目标，和以后的业务场景。
结合实际的情况，确切的性能指标和性能优化目标，来落地到实际的某一个具体步骤中。这可能才是长久之计。
