内容简介：构建高性能ASP.NET站点(下)
系列文章：
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求
构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析
构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能
本文第一篇：构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈
前言：从本篇开始就真正的进入了性能调优的阶段，在之前的文章中提到了页面加载过慢的四个性能问题，其中第一个问题就是：服务端解析.aspx页面的时间过长，本篇就分析这个问题，给出一些方案，因为涉及到的问题很多，的在后续文章会逐个详细介绍。
在服务端有很多可以优化的地方，优化的话题也很多，在本篇中我们主要关注：如果让服务端更快的生成页面，同时也关注如果更快的让生成的页面更快的到达客户端浏览器。
其实我们就是在优化下面的时间线：
要缩短上面的那条时间线，就需要服务端更好的利用它的资源，例如更好的利用和分配内存资源，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的一些设置来决定的。
如果在服务端没有足够的线程来处理请求，这种情况就是所谓的”线程饥饿”。我们可以通过系统的性能计数器来检查站点的服务端是否发生了这种情况：
1. 在命令窗口运行”perfmon”.如下：
2. 在打开的性能监视窗口中，选择”性能监视器”，如下：
3. 点击“+”按钮，然后展开”ASP.NET”分类：
4. 添加如下计数器：
5. 然后展开”ASP.NET Applications”分类，添加如下计数器：
如果”Request Current”的数量大于了Request Executing的数量，那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。
如果”Request Current”的数量大于了Request Executing的数量，那么就说明有请求在等待被处理。后面的文章会详细讲述如何处理这种情况。
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施
部署优化
我们都知道，不同的部署方式对站点的性能是有影响的，可能有些朋友已经知道了这点，不管怎样，我们这里还是详细系统的讲述一下这个问题，熟悉的朋友权当回顾J。
Release方式编译项目
如果我们的项目是用Project的方式建立的，也就是说：我们的站点包含在一个Solution解决方案中，那么在发布之前，编译项目的时候，采用release方式，这种方式会减少CPU的使用率。因为采用debug的方式发布，编译器会编译后的代码中加入很多的信息，如调试信息等。
操作步骤：
1. 在VS中，选择” Build | Configuration Manager”.如下：
2. 在”Active Solution Configuration”下拉框现在””Release”,然后”Close”.那么Solution就以Release方式编译。(其实使得Solution编译为Release的方法很多，例如在Solution上面右击”属性”，然后去设置也是可以的)
现在虽然Solution是Release方式了，但是如果我们去查看这个Solution下面的ASP.NET站点程序的config文件，发现还是deubg方式的。那么我们在发布站点的时候，需要手动的去修改为release。
注：如果Solution是以debug方式编译，即使web.config设置了release，最后发布的站点的代码还是方式的。
站点发布
发布的步骤如下：
1. 修改web.config配置如下：
2. 在站点上面右键选择”Publish”.如下：
减少不必要的回传
我们都知道，从服务端到客户端的回传每次都是需要花费一定的时间的，而且加长了用户等待的时间。所以有些回传则是可免则免。
Server.Transfer Vs Response.Redirect
如果我们需要在服务端把用户定向到另外的一个页面，那么考虑一下：尽量使用Server.Transfer，而不是使用Response.Redirect。
因为当使用Response.Redirect的时候，服务端会向客户端的浏览器发送一个响应：告诉浏览器去加载转向的那个页面。然后浏览器再次发送请求到服务端去请求另外的那个页面。
当我们使用Server.Transfer的时候，服务端就立刻执行跳转。这样做的一个不好的地方可能就是：此时请求的是A.aspx，其实服务端已经跳转到了B.aspx页面，但是浏览器上面的Url还是显示的A.aspx。
当使用Server.Transfer需要注意：确定每次访问A页面都需要跳转到B页面的时候，就是用Server.Transfer。例如，拿博客园来举例，当用户在没有登录的时候想对正在阅读的一篇文章评论，那么此时，页面就会跳转到Login的登陆页面，登陆之后，页面就跳转到之前看文章的那个页面，然后写评论。此时的这个跳转就不适合用Server.Transfer，而采用Response.Redirect。如果不管用户在哪里，只要用户登陆，那么总是跳到一个固定的页面，那么就可以使用Server.Transfer。
还有就是Server.Transfer毕竟会消耗服务端的资源，使用的时候要注意。
通过上面可以看出：调优本来就是一个折中的过程，不是绝对的。调优最后说到底就是”时空转换—时间换空间，空间换时间”。
声明站点的默认页面
当我们请求一个站点的时候，如http://domain/folder，IIS会自动进行一些重定向到http://domain/folder/。同时，http.sys也不会把没有声明默认页面的站点的默认首页加入到内核的缓存中(可能说的有点的绕)，例如，如果在程序中，我们设置站点的默认页面时Default.aspx，但是我们在部署到IIS的时候，没有配置Default.aspx就是站点的默认页面，那么这个页面的内容不会被http.sys缓存到内核中。所以为了避免IIS重定向和允许http.sys缓存页面，我们在IIS中要配置站点的默认页面(或者每次在浏览器中输入http://domain/folder/default.aspx，但是我们不能控制用户的行为，所以这招这几乎不可能)
永久跳转相关话题
如果我们站点的某个页面过期了或者不再用了，那么我们就可以采用301永久跳转。当服务端向客户端发出301响应的时候，浏览器和代理都会去更新他们的缓存(如果之前的旧页面采用了缓存)，而且搜索引擎也会采用新的页面。
要让服务端向客户端发送301响应，如下的方式：
1.代码：
Response.AddHeader("Location", "NewPage.aspx");
Response.End();
在ASP.NET 4.0 及以后的版本：
2. IIS配置
a) IIS 6配置
1. 在IIS中站点中，选中你想跳转的文件或者目录。
2. 选中”A redirection to a URL”
3. 然后输入你想跳转到的页面。
4. 然后选中”The exact url entered above”和”A permanent redirect for this resource”。
b) IIS 7
在Server 2008上面
1. 打开”开始”->”管理工具”->”服务器管理”
2. 在IIS上面添加”角色服务”
3. 在”常见Http功能”下面选中”Http重定向”
4. 然后安装。
在Win7 上面，如下：
然后，在我们的站点的web.config配置如下：
<location path="OldPage.aspx">
<system.webServer>
<httpRedirect enabled="true" destination="NewPage.aspx" httpResponseStatus="Permanent" />
</system.webServer>
</location>
</configuration>
构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求
服务端的要处理的请求越多，无疑服务端的压力也就越大，尤其是有些请求需要访问一些比较昂贵的资源，例如数据库，服务端的文件等。但是我们必须知道，在到达服务端的请求中，有些请求时我们希望的，例如网站的用户的请求，有些请求其实是不必要，甚至是我们不想要的，为此，我们要避免这样的请求，节省服务端的资源，从而提高性能。
搜索引擎
首先来看看有关搜索引擎的问题。
然后搜索引擎爬到我们的站点是一件好的事情，很多的SEO可以进行，推广站点。同时，在站点中，有些文件或者资源比较的私密，或者我们不希望被搜索引擎请求和收录的，因为每次搜索引擎在请求这些资源的时候，就是发送请求到我们的站点服务器，势必会加重服务器的负载。
不需要被搜索引擎请求的文件一般如下：
1. 图片资源
2. Js脚本，css等
3. 一些需要身份验证或者授权才能看的页面(如果页面需要验证之后才能看，搜索引擎收录了也作用不大)
我们可以设置一下，告诉搜索引擎的蜘蛛程序如何爬我们的站点。
步骤如下:
1. 在站点的根目录下面，创建一个robots.txt的文件。
2. 写入文件。如果我们希望阻止所有的搜索引擎来爬我们的站点的页面，那么就可以在文件中写入下面的配置：
User-agent: *
Disallow: /
如果希望阻止搜索引擎爬某个文件夹，可以配置如下：
User-agent: *
Disallow: /images/
Disallow: /js/
Disallow: /css/
Disallow: /private/
更有趣的是：对于某些搜索引擎，我们还可以改变他们的蜘蛛程序爬我们站点的频率，设置如下：
User-agent: *
Crawl-delay: 10
大家可以去上网找下一些如何影响Google，百度等蜘蛛程序的设置。
热链接问题
就是在A网站上面显示一个来自B网站的图片链接。例如我们在自己的站点上面有一个链接如下：<img src=”http://www.xxx.com/yyy.gif”/>，那么在别人在浏览我们的站点的时候，就回去别人的那个站点(http://www.xxx.com/yyy.gif)去请求这个图片，那么势必会消耗他们的服务器的资源。发过来，如果别人在他们的站点上采用了我们的图片或者其他的链接资料，那么用户在浏览别人的站点的时候就会消耗我们站点的服务端资源和带宽。
为一个组件就可以阻止这种情况的发生：http://www.iis.net/community/default.
aspx?tabid=34&i=1288&g=6.大家去看看。
验证码(CAPTCHA)
我们常常在站点中加入一些验证码的功能来防止网络注册机。一般是生成一张有文字的图片，然后根据验证用户输入的文字和图片中的文字是否一样来判断此时的用户是人还是注册机。
通过验证码阻止了注册机随意的消耗站点资源(如果没有验证码，注册机可以不断的注册信息，大小服务器和数据库资源，而且产生很多的垃圾数据)。
我们自己写生成验证码的程序，一般通过GDI+来做，同时也可以采用一些第三方的库实现，例如：reCAPTCHA: http://recaptcha.net/，大家上网找下，很多的。
网络刮刀(Scrapers)与Dos
这个问题必须引起重视。如果我们的站点上面有很多的有用的信息，那么别人可能就可能开发一个程序来到我们的站点抓取信息，然后把这些内容放到自己的站点上面。例如，很多的内容型的站点每天都从博客园的首页上面来抓取信息，然后放到他们的站点上，增加他们的访问量。
本来站点被搜索引擎抓就有点消耗性能了，如果还被很多的这样的网络刮刀来抓内容，对站点的性能影响可想而知。
如果那些网络刮刀程序的的IP地址变化不频繁，而且请求我们站点的频率比较的由规律，那么我们就可以采用一些代码的方式来防止这样的请求。例如，我们可以监测：同一个IP是否在20min之内发送了100个请求，如果是，我们就推测：可能是别人在抓我们的站点内容，我们就拒绝这个IP的请求。
当然了，上面只是一些简单的方法，对于一些复杂的Dos攻击，上面的监测代码基本没有作用。因为Dos攻击中，攻击的IP地址是变化的。
下面我们就写一些代码来防止简单的网络刮刀程序和简单的Dos攻击。基本的思想就是：如果在给定的时间段内，如果某个用户的请求很多，超过了一定的数量，那么我们就认为这个”用户”可能是网络刮刀程序，然后就拒绝下面的请求，一段时间之后，再次允许这个从这个IP发出的请求。
下面的代码中：假设如果一个用户在5秒之内发出了100个请求，那么我们就认为这是网络刮刀程序或者是网站的攻击者。当然，我们还考虑这个发送请求的”用户”是否是搜索引擎的蜘蛛程序。(下面的代码只是简单作为演示，不是实际生产的代码，抛砖引玉)
private const int maxRequestsInInterval = 5;
如果认为这个”用户”是攻击者，那么我们就阻止用户的请求，阻止时间是20秒
下面，我们创建一个类来描述一个访问者的信息。如下：
{
public int nbrHits;
public bool blocked;
public VisitorInfo()
{
nbrHits = 1;
blocked = false;
}
}
在BotDefence类中加入一个方法IsBotAttach来判断一个请求是否是攻击性的请求。如下：
{
string visitorIP = HttpContext.Current.Request.UserHostAddress;
VisitorInfo visitorInfo = (VisitorInfo)HttpContext.Current.Cache[visitorIP];
if (visitorInfo == null)
{
HttpContext.Current.Cache.Insert(
visitorIP, new VisitorInfo(), null,
DateTime.Now.AddSeconds(intervalSeconds),
System.Web.Caching.Cache.NoSlidingExpiration);
}
else
{
if (visitorInfo.blocked)
{
return true;
}
visitorInfo.nbrHits++;
if (visitorInfo.nbrHits > maxRequestsInInterval)
{
visitorInfo.blocked = true;
HttpContext.Current.Cache.Insert(
visitorIP, visitorInfo, null,
DateTime.Now.AddSeconds(blockedPeriodSeconds),
System.Web.Caching.Cache.NoSlidingExpiration);
return true;
}
}
return false;
上面的代码都是自解释的，很容易看懂，就不赘述了。 当然了，上面的代码很简单，我们可以保存每个请求IP的地址，然后分析。
构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析
内存问题概述
和CPU一样，内存也是一个直接影响服务端性能的重要的硬件资源。
一般来说，如果服务端内存不足，从导致以下两个问题产生：
1. 导致服务端把一些原本要写到内存中的数据，写到硬盘上面。这样不仅仅加大了CPU和磁盘的I/O操作，同时也延长了读取这些数据的时间。
2. 阻止了一些缓存策略的使用。
对于内存不足，一直最快最直接的方式就是去买内存条加在服务器上面。但是这样存在一个隐患的问题就是：如果加了新的内存之后，服务端又面临内存不足的问题，我们不可能无止境的加内存条，那么我们就必须从站点本身来解决这个问题，例如从服务端的配置，对站点的代码进行分析，优化。
托管资源优化
对于托管资源，相信大家并不陌生了，简单的说就是：在C#的托管堆上面创建的资源，或者说通过new产生的对象。
在深入讲解之前，我们首先来看看”对象的生命周期”
对象的生命周期
当我们用new关键字创建了一个对象的时候，这个对象就被分配到CRL托管堆上面。这个托管堆是在内存中的。而且这个分配对象空间的速度是非常的快的，因为每次都是在托管堆的最后面划出一定的空间来给这个对象，不用去堆上面需找合适大小的空间。
如果当托管堆准备为一个对象分配空间的时候，发现托管堆上面的空间太小了，不足以分配给这个新的对象，那么CLR就开始运行垃圾回收机制了。我们知道：垃圾回收机制会把那些在托管堆上面没有了引用指向的那些对象都清理掉，同时也会把托管堆上面现存的对象进行压缩。
但是有一点需要清楚：如果此时进行了垃圾回收的时候，清除了一些没有用的对象，但是只有在下一次来回收进行的时候，上次垃圾回收清除的对象才真正的从内存中消除(此时，还有一些“对象复苏“等话题就不在赘述)。
下面就来讲述一些垃圾回收的话题。
对象的”代“
在CLR进行垃圾回收的时候，垃圾回收器回去托管堆上面去检查对象是否可以被回收，这个检查过程是非常消耗资源的。为了避免每次垃圾回收都要便利托管堆上面的所有对象，CLR给把托管堆上面的对象用”代”来划分，例如，第一代，第二代。然后每次便利扫描托管堆的时候，就去扫描某一个”代”中的对象，这样性能就好点。
在托管堆上面，可以把对象分为三个”代”:0代，1代，2代，仅此这三个代。每个对象都是从0代开始的。一个对象每经历一次垃圾回收，并且这个对象还在使用中，那么这个对象的“代“就会增加1代。例如，如果在0代的对象，经历了一次垃圾回收之后，他的代就是1代，如果是1代的对象，最后就会变为2代。如果对象本身已经是2代了，不管经历多少次垃圾回收(如果对象一直在使用)，那么这个对象还是2代。
在CLR垃圾回收中有句话要记得:” ’代’数越大，被回收的可能性就越小”。而且一些性能优化就是根据这个进行的。
每次CLR在进行垃圾回收的时候，都会优先的去扫描第0代的对象，所以，一些新的，临时使用的对象可以被立刻的清除。相比而言，垃圾回收器扫描第1代对象的频率就没有第0代强，扫描第2代对象的频率就更低了。所以说：对象存活的时间越长，就越难被回收，而且一直占据CLR的内存资源。
还有有点需要注意的就是：如果CLR决定要扫描了第1代了，同时也用扫描第0代的对象，同时如果，CLR扫描第2代对象，那么第0代，第1代对象都会被扫描。
所以，从这里可以得出：我们尽量避免把原本需要立刻回收的的对象变为长期存活的对象。通俗点说就是：如果一个对象本来已经存活在0代的，然后用完就回收的，我们不要让这个对象一直存活到第1代，甚至第2代。在编程上面基本就是这样的实现思路：尽可能晚的实例化对象，尽可能早的释放对象。
大对象堆(Large Objecet Heap)
我们之前讲述了”堆”的一些话题，CLR除了上面的一般的堆(一般的new对象分配空间的那个堆)，CLR中还存在另外的一个堆：专门用来放置那些大于了85k的对象的堆，大对象堆。
如果new一个对象的时候，这个对象的大小超过了85k，那么CLR就会把这个对象放在LOH上面。如果此时LOH的空间不足了，那么CLR就会启动垃圾回收器去扫描LOH堆和那个一般堆上面的第2代对象，我们之前说过，如果扫描第2代对象，就同时扫描第1代，第0代，那么实际相当于扫描了整个托管堆，性能影响可想而知。
而且不想之前那个一般堆，在LOH上面的对象被垃圾回收器回收之后，上面的大对象是不会被压缩的，那么LOH这个堆上面就可能存在一些”空间碎片”，然后分配新的大对象的时候，就要找空间，甚至进行碎片的整理，大家可以联想一下我们电脑的磁盘碎片整理。
构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能
CLR计数器的使用
我们使用系统自带的性能监测工具来跟踪和监测垃圾回收器。
下面，首先介绍几个常用的CLR性能监测计数器，我们一般查看.NET CLR Memory分类下的计数器：
Percent Time in GC
表明了从上次垃圾回收机制运行之后到现在这段时间内，运行垃圾回收机制所花的时间占总时间的百分比。不要超过10%。
Gen 0 heap size
这个数值不是表明当前托管堆中Gen 0对象所占的大小，而是指：还可以分配的Gen 0对象的大小
Gen 1 heap size
表明当前Gen 1 对象所占的托管堆的空间大小
Gen 2 heap size
表明当前Gen 2 对象所占的托管堆的空间大小
Large Object Heap size
当前LOH的大小
# Byte in all Heaps
是上面Gen 0 heap size， Gen 1 heap size Gen 2 heap size， Large Object Heap size所有的种和，也就是整个托管堆所占的空间大小
# Gen 0 Collections
从系统开启之后到现在，垃圾回收器回收Gen 0对象的次数
# Gen 1 Collections
从系统开启之后到现在，垃圾回收器回收Gen 1对象的次数
# Gen 2 Collections
从系统开启之后到现在，垃圾回收器回收Gen 2对象的次数
介绍完上面的一些计数器之后，大家可以运行”perfmon”命令，打开性能监测工具。
下面开始介绍CLR Profiler（CLR 透析器）
CLR Profiler
CLR Profiler是微软开发的一个工具，这个工具可以用来检测CLR所占用的内存详情。
大家可以去下面的链接去下载这个工具：
http:// www.microsoft.com/downloads/details.aspx? familyid =a362781c-3870-43be-8926-862b40aa0cd0 &displaylang=en
下面的链接详细的讲述这个工具的用法：
http://msdn.microsoft.com/zh-cn/magazine/ee309515.aspx#MtViewDropDownText
在这里，只是简单的介绍一下如何使用，至于详细的操作，还请大家去查看上面给出的链接。使用的步骤如下：
1. 运行CLR Proflier
2. 确保”Profiling active, Allocations, Calls”都勾选上。如下：
3. 选择”File->Profile ASP.NET”.这个操作的背后会停止IIS的运行，然后插入一些指令，然后重启IIS，所以这个工具在生产环境中慎用。
4. 然后我们可以在VS中F5运行我们的网站(确保在创建网站的时候是以IIS方式来建立站点的，而不是选择”文件系统”的方式建立)
5. 在界面上面点击”Kill ASP.NET”.这个操作的背后会移除之前加入到IIS中的一些监视指令。点击按钮之后，会出现一些界面。这个界面上面显示了Gen0, Gen1 Gen2 ,LOH所占的大小,如下：
6. 我们还可以点击”Histogram”按钮。这个界面展示了不同大小以及不同类型的对象所占的比例。下面对看出，系统中有很多的string对象，也就说，系统中的string类型的对象占据了系统大部分的内存空间。
大家可以查看更多的信息，这里不再赘述了，下面我们来看看垃圾回收器的版本问题。
垃圾回收器版本
在CLR中，垃圾回收器是有两个版本的：
1. 服务端版本。CLR中的这个垃圾回收器版本进行了一系列的内存，处理器优化，用来进一步的提高性能。
2. 工作组版本，这是相对服务端版本而言的，主要是用在桌面开发中，例如在WPF，Winform中，就是采用的这个版本垃圾回收器。
在ASP.NET中就是采用的CLR服务端版本的垃圾回收器。
以上所述就是小编给大家介绍的《构建高性能ASP.NET站点(下)》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 构建高性能ASP.NET站点(上)
- 《高性能linux服务器构建实战》
- 构建高性能ASP.NET站点(中)
- 如何构建基于 Ceph 的高性能云存储解决方案？
- 高阶：腾讯新闻构建高性能的 react 同构直出方案
- 直播预约 | 在生产环境中，阿里云如何构建高性能云原生容器网络？
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
