构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈
前言：从本篇开始就真正的进入了性能调优的阶段，在之前的文章中提到了页面加载过慢的四个性能问题，其中第一个问题就是：服务端解析.aspx页面的时间过长，本篇就分析这个问题，给出一些方案，因为涉及到的问题很多，的在后续文章会逐个详细介绍。
因为本篇的篇幅过长，所以划分为了多篇。
本篇的议题如下：
识别和分析服务端的性能瓶颈(上)
内存
缓存
CPU
处理请求线程
提高性能的一些改进措施（下）
部署优化(前篇)
不必要回传(中篇)
不必要的请求(后篇)
系列文章链接：
构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求
在服务端有很多可以优化的地方，优化的话题也很多，在本篇中我们主要关注：如果让服务端更快的生成页面，同时也关注如果更快的让生成的页面更快的到达客户端浏览器。
其实我们就是在优化下面的时间线：
要缩短上面的那条时间线，就需要服务端更好的利用它的资源，例如更好的利用和分配内存资源，CPU资源等。如何好的充分利用这些资源，一定程度上与我们写的代码的质量息息相关，一段好的，高效的代码往往可以让我们少花钱去更多的硬件设备（所以代码的质量非常重要）。
下面我们就来看看服务端一般可能出现的性能瓶颈：
内存不足
缺乏缓存
CPU压力
处理请求线程问题
接下来会介绍如何采用系统的性能诊断工具来辨明：到底是哪种性能瓶颈导致了服务端解析页面过慢。在用性能诊断工具找出了问题之后，然后针对问题再次做详细的分析，同时收集数据，根据这些数据来采用对应的措施，对症下药。至于每一种性能问题如何采取何种措施解决，我们后面的文章会一章章的详细详述，请大家稍安勿躁，在此我们先学会发现问题。发现站点的可能出现了性能问题之后，首先不要立刻的修改站点或者服务器，而是要先诊断出瓶颈出现在哪里。J
内存
首先要判断服务器是否内存不足。因为如果内存不足，那么会增加服务器的CPU压力和磁盘的IO读写操作，发过来说，如果解决了内存不存的问题，自然而然的就减少了CPU和磁盘IO读写操作。
为什么内存不存会增加CPU的压力和磁盘的IO读写操作？
当系统的内存不足的时候，系统就会把原来需要放在内存的一些数据转移保存在磁盘上面，保存为pagefile.sys。当这些数据被需要的时候，那么系统就会去读写磁盘。读写磁盘的操作会消耗CPU资源，同时增加了磁盘的IO操作。
下面我们就来看看，如何识别内存不足性能瓶颈。
我们主要讲述如何在Window服务器系统中诊断这个问题。
Window Server 2003
在系统的命令行中输入”perfmon”。就会弹出如下的窗口。然后点击工具栏上面的”+”按钮，在”Performance object”下拉框中选择”Memory”，然后再选择”Pages/sec”计数器。如果这个值很大，就说明CPU在内存和磁盘之间不断的交换数据。
Windows Vista, Server 2008, Window 7
在Windows Vista和Windows Server 2008，Window 7中不仅可以运行”perfmon”，打开性能监视窗口。而且可以运行”resmon”来开启资源监视窗口，从这个窗口看，可以更加直观。在资源监视窗口中看到”硬错误/秒”(Hard Faults/sec).然后检查每个进程的这个值，如果进程的”硬错误/秒”数值很高，那么就说明服务器已经是内存不足了。（我们将会在后续的文章讲述如何解决这个问题，此处我们先讲述如何找出这个问题）
缓存
大家都知道，在适当的实用缓存策略可以极大的提高服务端的性能。我们一般把数据缓存在内存中，例如浏览器的内存，代理服务器的内存等。而且可以把一些常用的对象，部分的页面，甚至整个页面缓存起来。
缓存的好处有很多，如下：
缩短服务端的响应时间
减少CPU的使用压力
避免频繁的读取数据库
如果把数据缓存在浏览器或者代理服务器，还可以减少不必要的回传。
一般来说，我们把一些使用很频繁的数据或者每次生成都要花费大量资源的数据缓存起来。
但是如何才算得上是”使用很频繁”？
没有一定的标准了，还是那句话：看情况！例如，如果一个页面在1秒钟之内被请求了10次，可能相比较其他的页面而言，这个页面的请求不算””频繁（其他的页面在1秒之内请求100次)，但是如果把这个页面缓存1秒，也是对性能的极大提升，因为可以一秒之内，有90%的请求都是由缓存响应的。大家可以去参看一下”缓存的5分钟法则”。至于如何进行缓存，在后面的文章讲解。
CPU
还是和之前内存诊断一样，我们可以运行”perfmon”命令，然后在”Processor”分类下面选”%Processor Time”计数器。如下：
同时，我们还可运行”resmon”来打开“资源监视窗口”来看：
大家可以看到第一个标红色框的”CPU”列，其实这个就是反应了” %Processor Time”计数器监控的结果。一般来说，如果某个进程的这个值高于了80%，那么就说明这个进程对CPU资源有很大的消耗。如果是w3wp.exe这个进程消耗了80%，就说你的站点消耗了大量的CPU。我们会在后续的文章讲述：如果减小CPU的压力。
处理请求线程
我们知道：发送到服务器的每一个请求，都是有应用程序池中的一个线程来处理的。而且用来处理请求的线程的数量是有IIS来控制的，如果应用程序池中没有空闲的线程来处理新的请求，那么这个请求就被放在请求队列中进行等待。如果在服务端的请求队列太长了，服务器忙不过来，那么新来的请求很有可能被服务器拒绝。
一般来说，一个应用程序池中的可用的线程数量由服务端安装的.NET Framework的版本和IIS的一些设置来决定的。
|
.NET Framework Version |
默认的可用线程数 |
|
1.1． |
20*CPU的数量-8 |
|
2.0 |
12* CPU的数量 |
|
3.5, 4.0 |
IIS 7经典模式:12* CPU的数量 |
|
IIS 7 集成模式: 100* CPU的数量 |
如果在服务端没有足够的线程来处理请求，这种情况就是所谓的”线程饥饿”。我们可以通过系统的性能计数器来检查站点的服务端是否发生了这种情况：
1. 在命令窗口运行”perfmon”.如下：
2. 在打开的性能监视窗口中，选择”性能监视器”，如下：
3. 点击“+”按钮，然后展开”ASP.NET”分类：
4. 添加如下计数器：
|
Request Execution Time |
处理一个请求花费的时间(单位是：毫秒) |
|
Request Current |
现在ASP.NET运行时要处理的请求数量，包括正在处理的请求和等待队列中的请求。 |
5. 然后展开”ASP.NET Applications”分类，添加如下计数器：
|
Request Executing |
现在正在被处理的请求数 |
如果”Request Current”的数量大于了Request Executing的数量，那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。
如果”Request Current”的数量大于了Request Executing的数量，那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。
OK，今天就暂时发上这些，贵在理解和操作。下一篇接着讲述。