IIS配置优化

IIS配置优化

一、 设置应用程序池默认设置

二、 常规设置

三、 优化回收策略

四、 性能

五、 IIS初始化（预加载），解决（被回收后）第一次访问慢

六、 并发性

七、 安全性

八、 多服务器IIS集中化管理web

通常把站点发布到IIS上运行正常后，很少会去考虑IIS提供的各种参数，如何配置才是最适合当前站点运行需要的？这篇文章，从基本设置、回收机制、性能、并发、安全性等IIS设置讲解应当如何优化。

先来“IIS应用程序池”优化后的参数配置截图：

图中一些数值限制参数，可以借助一些工具（如：windows性能监控）观察站点运行的指标进行设置，具体后面会介绍到

下面来分别解说下这些参数为什么要这样设置（注：文章中的参数，不是按照应用程序池的设置从上到下排列的，而是按照优化的功能点排列）

一、 设置应用程序池默认设置

按如下图进行默认参数模板设置，设置后，新建的应用程序池就使用这个默认参数模板。

二、 高级常规设置

常规 > 启动32位应用程序

• 默认值：False
• 优化设置：按需设置。如果确认站点依赖一些32位的组件，需将此设置为true。
• 建议：为 32bit 应用程序的网站单独创建一个应用程序池

参考：

64位系统上iis运行32位的网站程序

常规 > 托管管道模式

-IIS7 应用程序池新增的经典模式和集成模式

• 经典模式：是为了保留和IIS6一样的处理方式，以前开发的代码，可以方便的移植到IIS7上。

• 集成模式：将ASP.NET请求管道与IIS核心管道组合在一起，这种模式与操作系统结合更紧密，能够提供更好的性能，能够实现配置和治理的模块化，而且增加了使用托管代码模块扩展IIS时的灵活性。

• 优化设置： 改为 Integrated（集成模式）

参考：

### 对IIS7经典模式和集成模式的理解

在经典模式下,IIS直接使用ISAPI扩展和ISAPI过滤器.并使用两个管道线,一个用于本机代码,另一个用于托管代码.您可以简单地说,在经典模式下,IIS 7.x与IIS 6一样工作,并且您无法从IIS 7.x功能中获得额外的好处. 在集成模式下,IIS和ASP.Net紧密耦合,而不是依赖于Asp.net上的两个DLL,就像经典模式一样.

三、 优化回收策略

回收 > 固定时间间隔（分钟）

一个时间段，超过该时间段，应用程序池将回收。值为 0 ，则应用程序池不会按固定间隔回收

默认值：1740分钟，29小时

优化设置：改为0 。因为无法避免在高峰期发生回收。同时设置“回收 > 特定时间”

回收 > 特定时间

应用程序池进行回收的一组特定的本地时间（24小时制）

优化设置：固定在低峰期时回收。eg：设定为 04:00 、15:30 等

另外，也可以使用windows计划任务实现iis站点每周六晚定时回收

进程模型 > 闲置超时（分钟）

一个时间段，设定工作进程允许保持闲置状态的最大时间间隔，超过该时间就会自动关闭。

优化设置：改为0，避免内存信息频繁被回收清空。同时设置“回收 > 特定时间”

进程模型 > 空闲超时操作

默认是“Terminate”（另一个选项是“Suspend”）。

Terminate 表示一旦超时就终止服务，并回收工作进程的缓冲区的内存；

Suspend 则悬停等待，暂不回收缓冲区内存。

另外：

CPU超限占用安全方案设置

CPU限制并不是用于控制每个进程的CPU利用率，而是一种处理发生CPU超限的工作进程的安全方案，这样可以避免工作进程占用CPU过久。

参考：

iis7.0 cpu 限制

iis中对cpu限制的操作：

1. 限制：10000 （以百分比*1000计算，10000则表示10%）

2. 限制操作：1、noaction 无操作 2、KillW3wp 删除进程 并在限制时间内重新开启新进程

3. 限制间隔（分钟）：设置时间限制，多久时间内重启和检测

内存超限回收机制

根据实际运行情况设定 “回收 > 虚拟内存限制” 和 “回收 > 专用内存限制”，默认为禁用状态，一般不用为此专门设定。

开启|关闭时间限制

根据实际运行情况设定，默认90秒。如上图，我都设置为了120秒

• 进程模型 > 关闭时间限制（秒）：为工作进程指定的，完成处理请求并关闭的时间段。如果工作进程超过关闭时间限制，将被终止。
• 进程模型 > 启动时间限制（秒）：为工作进程指定的，启动并进行初始化的时间段。如果工作进程初始化时间超过启动时间限制，将被终止。
• 回收 > 禁用重叠回收

默认值 false。应用程序池使用重叠回收方式。在这种方式下，当应用程序池要关闭某个工作进程时，会先创建一个工作进程，直到新的工作进程成功创建后才关闭旧的工作进程；

设置为 true，则先关闭旧的工作进程，然后再创建新的工作进程。 如果Web 应用程序不支持多实例运行，那么你必须配置应用程序池禁止使用重叠回收方式。

回收 > 生成回收事件条目

IIS事件查看器

方法一：点击“开始→运行”，输入eventvwr，点击“确定”，就可以打开事件查看器。

方法二：单击“开始”-“设置”-“控制面板”-“管理工具”-“事件查看器”，开事件查看器窗口。

方法三：在“运行”对话框中手工键入“%SystemRoot%/system32/eventvwr.msc /s”打开事件查看器窗口。

四、 性能

1. 关闭IIS日志

当开启记录功能后，IIS会事无巨细地忠实记录所有的web访问记录。这些记录文件的内容是非常庞杂的，比如访问时间、客户端IP、从哪个链接访问、 Cookies等，另外还包括 Method(方法), UserAgent(用户代理)等。这些记录不但占用大量的磁盘空间还大大地影响了web服务器的性能。有人做过评测，停止访问记录可以提升5%到8%的web性能。

1. 启用内容过期（客户端缓存）

对于静态文件启用内容过期可以提高访问性能。

1. 首先网站的目录要划分合理，图片、CSS、JavaScript均放在单独目录下

2. 然后在IIS中选择要缓存的目录 > HTTP 响应标头 > 设置常用标头 > 设置"web内容过期"策略

如上图webDemo站点，这样，用户浏览器将比较当前日期和截止日期，以便决定是显示缓存页还是从服务器请求更新的页，由于图片、CSS、JS通常变化较少，因此基本上都从本地缓存读取，从而加快显示速度。

参考：

IIS7禁用单个静态文件的客户端缓存

1. 服务器验证缓存

IIS自动机制，会在访问css、js等静态文件时，返回给浏览器Last-Modified和Etag标记

参考：

浏览器缓存之Last-Modified

服务端的缓存验证 Last-Modified和Etag

1. 启用Gzip压缩

IIS 压缩功能使用Gzip算法

gzip是HTTP的一种压缩算法，HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。HTTP压缩采用通用的压缩算法如gzip等压缩HTML、JavaScript或 CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。当然，同时也会增加一点点服务器的负担。Gzip是比较常见的一种HTTP压缩算法。

五、 IIS初始化（预加载），解决（被回收后）第一次访问慢

参考：https://www.cnblogs.com/teamblog/p/6195078.html

设置之后，什么时候会自动初始化？

（比如初始化执行 Global.Application_Start 初始化函数）

1. 会 - 应用程序池启动、应用程序池回收、cmd->iisreset （w3wp的PID会变）

2. 不会 - 站点重启（IIS站点右键 > 管理网站 > 重新启动）、站点启动

3. 不会 - web.config更改引起的应用程序池回收

在IIS10版本上测试是上面行为。另外有人IIS8.5上使用也是同样的行为，参考文章。

步骤一、安装IIS应用程序初始化功能

步骤二、设置IIS上应用程序池启动模式

常规 > 启动模式

默认值：OnDemand（按需运行模式），另外值AlwaysRuning（始终运行模式）

优化设置：改为 AlwaysRunning（始终运行）

步骤三、设置站点预加载

在IIS上站点右键 > 管理网站 > 高级设置，把【预加载已启用】设置为true。

步骤四、配置站点 web.config ，添加站点重启后预加载请求的页面

eg：地址：http://webdemo.com/home/about

这样操作保存后，IIS会修改 web.config 添加如下内容

<system.webServer>
    …… 
    <applicationInitialization doAppInitAfterRestart="true">
        <add initializationPage="home/about" hostName="" />
    </applicationInitialization>
</system.webServer>
如果只是初始化（比如只执行 Global.Application_Start 初始化函数），不需要访问特定API进行额外资源的初始化，则不需要 <add initializationPage="**" /> 子节点

 

六、 并发性

常规 > 队列长度

• HTTP.sys 将针对应用程序池排队的最大请求数。默认值1000，最大值65535。

1. 如果设置太大则会消耗大量的系统资源 ，而设置太小会导致客户端访问时频繁出现"503服务不可用"响应。
2. 优化设置：可先改为 5000（设置为预期最多并发用户数的1.5倍，官方参考

使用windows性能监控（性能监控：cmd->perfmon.msc），添加“HTTP Service Request Queues/CurrentQueueSize”指标，观察某个应用程序池当前队列中请求的个数。

• 启用Web园（Web Garden），进程模型 > 最大工作进程数

在Web园中你可以配置此应用程序池所使用的最大工作进程数，默认为1，最大可以设置为4000000； 配置使用多个工作进程可以提高该应用程序池处理请求的性能，但是在设置为使用多个工作进程之前，请考虑以下两点：

1、每一个工作进程都会消耗系统资源和CPU占用率；太多的工作进程会导致系统资源和CPU利用率的急剧消耗；
2、每一个工作进程都具有自己的状态数据，如果Web应用程序依赖于工作进程保存状态数据，那么可能不支持使用多个工作进程。
这样设置，增加了处理进程数，相当于集群，避免大量请求处于排队状态

参考：

• IIS并发优化

文章介绍：使用windows性能监控：cmd->perfmon.msc。监控IIS应用运行情况，再根据需要进行iis参数设置 Web
Service/Current Connections 监控某个应用程序池来指示当前该应用程序池的连接的数量。
ASP.NET Apps v4.0.30319/Requests Executing 监控所有的 ASP.Net 4.0 正在处理中的请求数量。
ASP.NET v4.0.30319/Requests Current 与上述类似用于监控 Asp.Net 4.0 正在处理中的请求数量。
HTTP Service Request Queues/CurrentQueueSize 用来监控某个应用程序池当前队列中请求的个数。

• 调整支持并发请求的数量

默认支持并发请求数量为：5000

超出此并发数，会报异常

HTTP Error 503.2 - Service Unavailable

The serverRuntime@appConcurrentRequestLimit setting is being exceeded.

参考：

IIS 并发请求设置如何设置？

站点最大并发连接数

右键站点 > 高级设置 > 限制 > 最大并发连接数

设置站点线程数：工作线程(最大\最小工作进程数): minWorkerThreads、maxWorkerThreads、最大IO数 ：maxIoThreads

maxWorkerThreads默认20，maxIoThreads默认20，minWorkerThreads默认1，minIoThreads默认1 ( eg：8核，默认分别就是160, 160, 8, 8 )

1、配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

2、修改参数：

其中：minWorkerThreads = maxWorkerThreads / 2 ; minIoThreads = maxIoThreads / 2

参数具体值如何设置，还需要各自对站点进行压力测试中调整

参考：

    博客园"黑色30秒"事件

            排查“黑色30秒”问题-为什么请求会排队

            [解决]从ASP.NET线程角度对“黑色30秒”问题的全新分析

IIS7.5优化–提高线程数来适应高并发

processModel 元素（ASP.NET 设置架构）

Improving ASP.NET Performance （微软文档中给出了推荐值，如下图）

七、 安全性

为不同工作进程指定应用程序池（工作进程隔离模式）

一台服务器上有非常多的Web站点。如何才能做到各个站点之间相互独立，不因某些Web站点出现故障而影响其他站点呢?–为不同工作进程指定应用程序池是个很好的解决办法。

进程模型 > 标识，使用ApplicationPoolIdentity虚拟账户

ApplicationPoolIdentity – 默认情况下，选择“应用程序池标识”帐户。启动应用程序池时动态创建“应用程序池标识”帐户，因此，此帐户对于您的应用程序来说是最安全的。（这样，每个应用程序池都有各自的账户，就避免了木马上传到其中一个池下站点，会对另一个池的文件夹有操作权限）

参考：

IIS7.5中神秘的ApplicationPoolIdentity

启用快速失败保护

如果Web应用程序代码编写有问题，它可能会导致工作进程持续出现问题。默认情况下应用程序池配置为启用快速失败保护，当工作进程在配置的时间段（默认为5分钟）内发生的失败次数超过了配置的值（默认为5次），则禁用此应用程序池。

八、 多服务器IIS集中化管理web

Microsoft IIS Administration 微软提供，管理IIS配置的REST API 和集中化IIS管理WEB UI。

l 支持绝大部分IIS配置项管理

l 支持管理远程IIS，实现集中化IIS配置管理。

l 支持REST API，方便集成到自研系统。

l 支持IIS配置访问安全性设置

详细查看：多服务器IIS集中化管理web和编程访问IIS

其他阅读：

         IIS 开启和关闭详细报错信息（404,500,502等）

IIS 配置集中式证书模块实现网站自动绑定证书文件

CertSvc 实现IIS自动证书续签维护

CertSvc 是一个免费的证书托管平台，整合 ZeroSSL 和 Let’s Encrypt 的ACME协议，支持自动签发通配符泛域名证书，并集成部署工具，部署一次即可免去定期维护证书的工作，支持 Linux 、Window 服务器。

===========================================================

九、附录：

1.集成和经典应用程序池模式

• 集成应用程序池模式

当应用程序池处于集成模式时,您可以利用IIS和ASP.NET的集成请求处理体系结构.当应用程序池中的工作进程收到请求时,请求将通过有序的事件列表.每个事件都调用必要的本机和托管模块来处理部分请求并生成响应.

在集成模式下运行应用程序池有几个好处.首先,IIS和ASP.NET的请求处理模型被集成到统一的流程模型中.此模型消除了以前在IIS和ASP.NET中重复的步骤,例如身份验证.此外,集成模式可以为所有内容类型提供托管功能.

• 经典应用程序池模式

当应用程序池处于经典模式时,IIS 7.0将处理IIS 6.0工作进程隔离模式中的请求.ASP.NET请求首先在IIS中执行本机处理步骤,然后路由到Aspnet_isapi.dll以处理托管运行时中的托管代码.最后,请求通过IIS路由回来发送响应.

IIS和ASP.NET请求处理模型的这种分离导致一些处理步骤的重复,例如认证和授权.此外,托管代码功能(如表单身份验证)仅适用于ASP.NET应用程序或应用程序,您可以使用脚本映射所有要由aspnet_isapi.dll处理的请求.

在将生产环境升级到IIS 7.0并将应用程序分配到集成模式下的应用程序池之前,请确保在集成模式下测试现有应用程序的兼容性.如果应用程序无法在集成模式下工作,则只应在经典模式下将应用程序添加到应用程序池.例如,您的应用程序可能依赖于从IIS传递到托管运行时的身份验证令牌,并且由于IIS 7.0中的新体系结构,该进程会破坏您的应用程序.

2. IIS 提高线程数来适应高并发

根据压测结果做出的修改历史：
第一步：只针对maxWorkerThreads、maxIoThreads和minWorkerThreads做了修改，发现并无明显性能提升。

第二步：针对第一步，提高了三个参数的值maxWorkerThreads=“200” maxIoThreads=“200” minWorkerThreads=“100” 。并且修改了“每个处理器的线程数限制”，从默认值25提高到50，顺便修改了队列长度从3000到30000。此时，性能有明显提升。

第三步（未执行）：修改应用程序池的“最大工作进程数”，即使用IIS的Web Garden功能（多工作进程模式）。

总结：一开始只是提高了IIS的最大、最小线程数，但是由于ASP的每个处理器的线程数限制（25），所以性能并没有明显提升。后来提高了ASP的每个处理器的线程数限制，性能才有明显好转，但直接表现是站点进程的CPU和使用线程数明显升高，导致服务器本身负载飙升。目前这种较为粗暴的直接增大参数指标的优化方式比较适用于服务器上的单站点或者单个负载较高的站点，如果一台服务器上有几个负载加高的站点，会导致服务器本身资源损耗严重反而影响站点的处理能力，第三步的Web Garden尤为明显。所以，应该持续压测、观察来找到一个较为适合我们服务器和站点结构的参数配置。

以下参考文档是对以上参数的释义及修改方法：
1、maxWorkerThreads、maxIoThreads
ASP.NET 使用以下两个配置设置来限制工作线程和完成线程所使用的最大数目︰

配置文件：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
修改参数：

MaxWorkerThreads参数和maxIoThreads参数隐式地乘以 Cpu 的数量。例如，如果您有两个处理器，是以下的最大工作线程数︰

2*maxWorkerThreads

2、minWorkerThreads从 ASP.NET 1.0 Service Pack 3 和 ASP.NET 1.1 中，ASP.NET 还包含以下确定多少工作线程可能会使可立即用于远程请求提供服务的配置设置。

此设置控制的线程可以在更快的速度比从 CLR 的默认"线程优化"功能创建的辅助线程创建。可能突然填充 ASP.NET 请求队列的后端服务器上的 slow-down 由于此设置启用 ASP.NET 服务请求、 请求来自客户端，或其它类似突然爆发，会导致在队列中的请求数量突然上升。MinWorkerThreads参数的默认值为 1。我们建议您将minWorkerThreads参数的值设置为下面的值。
minWorkerThreads = maxWorkerThreads / 2
默认情况下，不存在 Web.config 文件或 Machine.config 文件中的minWorkerThreads参数。此设置隐式乘以
3、优化每个处理器限制对线程 ASP 属性的值（默认25，已修改成50）
ASP处理器限制每个线程属性指定的最大工作线程为每个 IIS 创建的处理器数。 之前的处理器使用率满足至少 50%或更高版本，应增加处理器限制每个线程的值。 此设置可能大大会影响 Web 应用程序的可伸缩性和服务器的性能通常。 因为此属性定义的最大可以同时执行的 ASP 请求数，此设置应保持为默认值，除非你 ASP 应用程序进行扩展的外部组件调用。 在这种情况下，可能会增加处理器限制每个线程的值。 这样做将使要创建更多的线程，以处理更多的并发请求的服务器。 处理器限制每个线程的默认值为 25。 此属性的最大建议的值为 100。

若要增加处理器限制每个线程的值，请执行以下步骤： 在连接窗格中，选择 web 服务器，请单击以选中功能视图，然后双击ASP功能。

单击启动，指向所有程序，单击管理工具，然后单击Internet Information Services (IIS) Manager.

在连接窗格中，选择 web 服务器，请单击以选中功能视图，然后双击ASP功能。

单击以展开限制属性下行为，单击处理器限制每个线程，输入所需的值线程每个处理器限制单击应用中操作窗格。

4、优化 ASP 队列长度属性的值（默认3000，已修改成30000）
优化此属性的目标是确保良好的响应时间，同时最小化 ASP 请求队列已满时，服务器频率发送到客户端的 HTTP 503 （服务器太忙） 错误。 如果 ASP 队列长度属性的值太低，则服务器将使用更高的频率发送 HTTP 503 错误。 如果 ASP 队列长度属性的值过高，所以用户可能会认为，服务器没有响应时实际上他们的请求正在等待队列中。 通过在高流量期间观看队列，你应识别 web 请求高峰和低谷的模式。 记下的峰值值，并设置正上方的峰值值 ASP 队列长度属性的值。 使用队列以处理短期峰值，请确保响应时间，并限制系统，从而避免重载时持续，出现意外的峰值。 如果你没有用于调整 ASP 队列长度属性的数据，将是很好的起点将队列一对一比率设置为线程的总数。 例如，如果每个处理器限制对线程 ASP 属性设为 25，具有四个处理器 (4 * 25 = 100 线程)，将 ASP 队列长度属性设置为 100 并从该处优化。

若要增加队列长度的值属性，请按照下列步骤：

单击启动，指向所有程序，单击管理工具，然后单击Internet Information Services (IIS) Manager.

在连接窗格中，选择 Web 服务器，请单击以选中功能视图，然后双击ASP功能。

单击以展开限制属性下行为，单击队列长度，输入所需的值队列长度，然后单击应用中操作窗格

5、Web Garden
IIS默认配置下采用的是单工作进程的工作模式，也就是只启用一个w3wp.exe进程处理所有请求，然后进程内启用多个线程来处理并发请求，最大工作线程数由具体的操作系统和IIS来决定，当并发量大于线程数时则会让请求排队等待处理。这是面对高并发量，且部分请求处理耗时较长时就会造成大部分请求长期处于挂起的状态，直接反应就是慢或者超时。

3、线程池设置的数据问题

一、线程池的默认设置

先看看微软官方的说法：

maxIoThreads 默认值为 20。该属性的范围是从 5 到 100。
maxWorkerThreads 默认值为 20。该属性的范围是从 5 到 100。
minIoThreads  默认值为 1。
minWorkerThreads 默认值为 1。
requestQueueLimit 默认值为 5000。 

jeffer richer 说明

.net 2.0 每CPU25个线程，同时不建议修改默认配置 ,而且网上很多人也认为是25个，但我没有测出这个结果.

我测试的情况：

我机器为双核 ，autoconfig=“true”

windows Application ：

最大线程数： 500
最小
最大IO数：1000

web Application：
最大线程数为:200
最大IO数：1000
测试方法：

int i = 0;
int j = 0;
System.Diagnostics.Stopwatch watch = new Stopwatch();
watch.Start();

ThreadPool.GetMaxThreads(out i, out j);

Response.Write("最大工作线程"+i.ToString() + "/r/n");
ThreadPool.GetMinThreads(out i, out j);
Response.Write("最小工作线程" + i.ToString() + "/r/n");


ThreadPool.GetAvailableThreads(out i, out j);

Response.Write("可用线程:"+i.ToString()+"/r/n");
Thread.Sleep(5000);
watch.Stop();
decimal tim = watch.Elapsed.Ticks / 10m;
Response.Write("花费时间为:" + tim.ToString());

说明：根据测试的确最小线程数和MSDN上所述一致，默认为1;但最大线程数应该为：windows应用(cpu数250),web应用(cpu数100) ，所以如果autoconfig=“true” 最大线程数并不是20，也不是25，而是100,在不同的机器上测试的结果一致。

二、优化的意义

按照官方的说法，线程的创建要耗费大量的系统资源，所以当用户访问量极大时，应该提高minWorkerThreads数和其它的配置， 将autoconfig=“false”

修改为假，同时指定maxWorkerThreads=“20” minWorkerThreads=“10” ,同时在上述代码中将线程休眠5秒，压500并发，在测试的后半段发现可用线程数（最大线程数-已用线程数）达到9个左右，当停止并发后，要过一段可用线程数才能恢复，本来认为设定范围较大，又进行了重新设置将maxWorkerThreads=“10” minWorkerThredad=“5”,又压了一次，发现可用线程数维持在7左右，并没有耗尽，所以初步认为ThreadPool内部有自己的保护机制，可用线程数要预留一定数量以应对其它的处理。

4.IIS7.5中神秘的ApplicationPoolIdentity

IIS7.5中(仅win7,win2008 SP2,win2008 R2支持)，应用程序池的运行帐号，除了指定为LocalService,LocalSystem,NetWorkService这三种基本类型外，还新增了一种ApplicationPoolIdentify

win7的官方帮助上是这么说的:

ApplicationPoolIdentity – 默认情况下，选择“应用程序池标识”帐户。启动应用程序池时动态创建“应用程序池标识”帐户，因此，此帐户对于您的应用程序来说是最安全的。

也就是说"ApplicationPoolIdentity"帐号是系统动态创建的“虚拟”帐号(说它是虚拟的，是因为在用户管理里看不到该用户或用户组，在命令行下输入net user也无法显示，但该帐号又是确实存在的)

如何验证该帐号确实是存在的的？打开任务管理器，观察一下:

w3wp.exe即iis进程，上图中高亮部分表明该iis进程正在以帐号luckty运行(注意这里的luckty即为上图中的应用程序池名称)

好了，搞清楚这个有什么用?

先来做一个测试，比如我们在iis里新建一个站点，主目录设置为c:\2\，应用程序池就指定刚才图中的luckty

假如我们在该站点的default.aspx.cs里写入这样一行代码 :

File.AppendAllText(“C:\TestDir\1.txt”,DateTime.Now.ToString());

前提是c盘必须先建一个目录TestDir，同时除Administrator,System保留完全控制权外，其它帐号的权限都删除掉

运行后，会提示异常： 对路径“C:\TestDir\1.txt”的访问被拒绝。

原因很明显:该站点运行时是以应用程序池(luckty)对应的虚拟帐号运行的，而这个虚拟帐号不具备c:\TestDir的访问权限

这种情况在web服务器（iis6）安全配置中很常见，比如我们把图片上传目录，常常放在主目录之外，同时以虚拟目录形式挂于站点之下，另外在IIS6中不指定该目录任何执行权限 ，这样即使有人非法上传了asp/aspx木马上去，也无法运行搞不成破坏!

言归正传，要想让那一行测试代码正常运行，解决办法很简单，把虚拟帐号的权限加入文件夹安全权限中即可，但是问题来了：这个虚拟帐号我们是不可见的，如果你直接添加名为luckty的用户到文件夹安全帐号里，根本通不过(提示找不到luckty用户)，说明这个虚拟帐号名称并不是"luckty"

关键：手动输入 IIS AppPool\luckty （即IIS AppPool\应用程序池名），再确定，这回ok了.

当然除了用"IIS AppPool\应用程序池名"外，windows内部还有一个特殊的用户组Authenticated Users，把这个组加入TestDir的安全权限帐号里也可以，不过个人觉得没有"IIS AppPool\应用程序池名"来得精确.

结束语：
IIS7.5的虚拟帐号设计确实很棒，想想传统IIS6的时候，为了把同一服务器上的各站点权限分开(以防止木马捣乱)，不得不创建一堆iuser_XXX,iwam_XXX帐号并指定密码，再一个个站点分配过去，累死人！而虚拟帐号设计则让这类管理轻松多了，也不用担心密码过于简单或过期问题。So,还在等什么，赶紧升级到win7/win2008 R2吧！