processModel与ASP.NET进程模型

配置 Microsoft Internet 信息服务 (IIS) Web 服务器上的 ASP.NET 进程模型设置。其作用是配置IIS或IIS中的应用程序池(IIS7及以后版本)的安全性,性能,健壮性,可靠性。

processModel 节只能在 Machine.config 文件中进行设置,它影响服务器上运行的所有 ASP.NET 应用程序。Machine.config文件则位于Windows\Microsoft.NET\Framework64\{.Net Framework Version}\Config或Windows\Microsoft.NET\Framework\{.Net Framework Version}\Config中。

其配置节内容和默认设置如下,查看各个属性的作用可参考https://msdn.microsoft.com/zh-cn/library/7w2sway1(VS.80).aspx

在IIS6中引入了应用程序池,在应用程序池的高级设置中就包含了processModel的设置,其中应用程序标识的配置和idleTimeout的设置在Machine.config和应用程序池高级设置中都存在,但是就以应用程序池的为准了。

如在Machine.config中设置userName和password,

    <processModel
    userName="Administrator"
    password="111" />

通过任务管理器查看进程的

以及通过以下代码查看进程的用户名时均无生效

        string GetProcessUserName(int pID)
        {
            string text1 = null;

            SelectQuery query1 = new SelectQuery("Select * from Win32_Process WHERE processID=" + pID);
            ManagementObjectSearcher searcher1 = new ManagementObjectSearcher(query1);

            try
            {
                foreach (ManagementObject disk in searcher1.Get())
                {
                    ManagementBaseObject inPar = null;
                    ManagementBaseObject outPar = null;

                    inPar = disk.GetMethodParameters("GetOwner");

                    outPar = disk.InvokeMethod("GetOwner", inPar, null);

                    text1 = outPar["User"].ToString();
                    break;
                }
            }
            catch
            {
                text1 = "SYSTEM";
            }

            return text1;
        } 

但是在应用程序池的高级设置中设置则生效

同理,设置闲置超时(idleTimeout)同样都是在应用程序池中设置才生效,在Machine.config中设置超时时间为1分钟,

<processModel
idleTimeout="1"/>

在应用程序池中设置为2分钟

访问站点后留意"任务管理器"中w3wp进程消失的时间,就会发现在静置两分钟后w3wp被结束掉。

经过观察还发现了其他虽然不是重名的属性,但是看其作用相似的,本人未去验证其有效性,但也列举出来

Machine.config ----------- 应用程序池

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

shutdownTime --------------- shutdownTImeLimit

pingInterval --------------- pingFrequency

pingResponseTime------------ pingTimeout

webGarden --------------- maxProcesses设置成大于1时

此外单纯出现在Machine.config配置节的属性还是会生效的,例如通过查看应用程序池的线程数量来看对maxWorkerThreads和maxIoThreads是否会生效。

在Machine.config中添加以下设置。

    <processModel
         autoConfig="false"
         maxWorkerThreads="1000"
         maxIoThreads="999" />

WebForm页面的Page_Load方法添加以下代码

int work,io;

ThreadPool.GetMaxThreads(out work, out io);

this.lb1.Text += string.Format("<br/> work {0} io {1}",work,io);

运行后发现执行结果如下

这里额外说明一下,如果autoConfig设置成true,它会自动设置maxWorkerThreads和maxIoThreads,如需使用用户自定义设置,则需要设置成false,另外maxWorkerThreads和maxIoThreads是单个CPU中工作线程与IO线程的数量,鄙人的电脑是双核四线程,所以实际运行出来的结果是该设置值的4倍。

关于性能这一方面鄙人参考了微软上面的一篇文章,阅读之后总结了以下几点

1.实际线程池的maxWorkerThreads和maxIoThreads是配置节中

maxWorkerThreads*CPU数

maxIoThreads*CPU数

2.minWorkerThreads最好设置成 minWorkerThreads = maxWorkerThreads / 2

3.单个CPU最多处理的请求数目为 (maxWorkerThreads*number of CPUs)-minFreeThreads,minFreeThreads是httpRuntime配置节的Attribute

4.If you are making one Web service call to a single IP address from each ASPX page。Microsoft 建议您使用以下配置设置︰

•将maxWorkerThreads参数和maxIoThreads参数的值设置为100。

•设置的maxconnection参数的值 12 *N (N是CPU数量)。

•设置的minFreeThreads参数的值 88 *N 和minLocalRequestFreeThreads参数76 *N.

•MinWorkerThreads为50

例如,您有带四个处理器和启用超线程的服务器。根据这些公式,将本文中提到的配置设置使用下列值。

<system.web>
  <processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
  <httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>
<system.net>
  <connectionManagement>
    <add address="[ProvideIPHere]" maxconnection="96"/>
  </connectionManagement>
</system.net>

参考文章

https://support.microsoft.com/zh-cn/kb/821268

https://msdn.microsoft.com/zh-cn/library/7w2sway1(VS.80).aspx

https://www.iis.net/configreference/system.applicationhost/applicationpools/add/processmodel

时间: 2025-01-05 16:34:11

processModel与ASP.NET进程模型的相关文章

Asp.net管道模型(管线模型)

前言 为什么我会起这样的一个标题,其实我原本只想了解asp.net的管道模型而已,但在查看资料的时候遇到不明白的地方又横向地查阅了其他相关的资料,而收获比当初预想的大了很多. 有本篇作基础,下面两篇就更好理解了: 理解并自定义HttpHandler 理解并自定义HttpModule 目录 一般不写目录,感觉这次要写的东西有些多就写一个清晰一下吧. 1.Asp.net管道模型: 2.进程的子进程与进程的线程: 3.应用程序域(AppDomain): 4.IIS5.x下一个HTTP请求/响应过程的整

ASP.NET路由模型解析

大家好,我又来吹牛逼了 ~-_-~ 转载请注明出处:来自吹牛逼之<ASP.NET路由模型解析> 背景:很多人知道Asp.Net中路由怎么用的,却不知道路由模型内部的运行原理,今天我就给大家吹下ASP.NET的路由模块是如何工作的. ps:这是针对ASP.NET4.5版本的,好像在最新的5.0版本中加入了OWIN,彻底解耦了和Web服务器的耦合,我还没有研究过,不敢妄言4.5的模型适用5.0.(是不是被我严谨的态度震慑了_-_) action*0x1:大话ASP.NET模型 首先我们先来了解下一

nginx进程模型 master/worker

nginx有两类进程,一类称为master进程(相当于管理进程),另一类称为worker进程(实际工作进程).启动方式有两种: (1)单进程启动:此时系统中仅有一个进程,该进程既充当master进程的角色,也充当worker进程的角色. (2)多进程启动:此时系统有且仅有一个master进程,至少有一个worker进程工作. master进程主要进行一些全局性的初始化工作和管理worker的工作:事件处理是在worker中进行的. 首先简要的浏览一下nginx的启动过程,如下图: 2.实现原理

Esper学习之三:进程模型

之前对Esper所能处理的事件结构进行了概述,并结合了例子进行讲解,不清楚的同学请看Esper学习之二:事件类型.今天主要为大家解释一下Esper是怎么处理事件的,即Esper的进程模型. 1.UpdateListener UpdaterListener是Esper提供的一个接口,用于监听某个EPL在引擎中的运行情况,即事件进入并产生结果后会通知UpdateListener.接口如下 [java] view plaincopy package com.espertech.esper.client

nginx源码分析--master和worker进程模型

一.Nginx整体架构 正常执行中的nginx会有多个进程,最基本的有master process(监控进程,也叫做主进程)和woker process(工作进程),还可能有cache相关进程. 一个较为完整的整体框架结构如图所示: 二.核心进程模型 启动nginx的主进程将充当监控进程,而由主进程fork()出来的子进程则充当工作进程. nginx也可以单进程模型执行,在这种进程模型下,主进程就是工作进程,没有监控进程. Nginx的核心进程模型框图如下: master进程 监控进程充当整个进

nginx源码分析--高性能服务器开发 常见进程模型

1.高性能服务器 对一个高性能服务器来说,处理速度快和资源占用小是典型特性,尤其是当服务器遇到C10K问题的时候(网络服务器在处理数以万计的客户端连接时,往往出现效率低下甚至完全瘫痪,这被称为C10K问题).要做到处理速度足够快,其并发模型的设计相当关键,而要做到资源尤其是内存资源的占用少,就要依赖于其资源分配和资源管理的方案设计. 服务器的并发模型设计是网络编程中很关键的一个部分,服务器的并发量取决于两个因素,一个是提供服务的进程数量,另外一个是每个进程可同时处理的并发连接数量.相应的,服务器

[转] ASP.NET MVC 模型绑定的功能和问题

摘要:本文将与你深入探究 ASP.NET MVC 模型绑定子系统的核心部分,展示模型绑定框架的每一层并提供扩展模型绑定逻辑以满足应用程序需求的各种方法. 同时,你还会看到一些经常被忽视的模型绑定技术,并了解如何避免一些最常见的模型绑定错误. ASP.NET MVC 模型绑定通过引入自动填充控制器操作参数的抽象层.处理通常与使用 ASP.NET 请求数据有关的普通属性映射和类型转换代码来简化控制器操作. 虽然模型绑定看起来很简单,但实际上是一个相对较复杂的框架,由许多共同创建和填充控制器操作所需对

nginx源码分析--框架设计 &amp; master-worker进程模型

Nginx的框架设计-进程模型 在这之前,我们首先澄清几点事实: nginx作为一个高性能服务器的特点,其实这也是所有的高性能服务器的特点,依赖epoll系统调用的高效(高效是相对select/poll这些系统调用的,底层有一个链表和红黑树,避免了轮询,减少了用户空间和系统空间之间的数据传递等),非阻塞(所有的操作都是非阻塞,这样),多进程(master-slave进程模型),这些事实使得nginx成为一个高性能服务器的前提条件. 既然作为一个软件(http服务器),相对于一个网络库而言肯定有更

Nginx(十)-- 进程模型及工作原理

1.nginx进程模型 Nginx是一个master和worker的模型.master主要用来管理worker进程,master就比作老板,worker就是打工仔,master指挥worker来做事情.下图是nginx的进程模型: master进程: 1.接收外界的信号,例如:kill -QUIT,kill -HUP   kill -HUP 重新加载配置文件,然后重新启动新的worker进程,老的还在运行,同时,向老的worker进程发送退休命令,老的worker进程将原有的请求处理完之后,就退