HttpRuntime请求处理周期
validationinterval参数
validationinterval参数ValidationInterval参数是.NET框架提供的参数之一，它可以用于在 Web应用程序中指定多长时间进行一次验证。
这个参数的主要作用是定制化控制验证事件触发的时间间隔。
下面我们从以下几个方面来详细了解ValidationInterval参数是如何使用的。
### 1. 如何设置ValidationInterval参数在框架中，我们可以通过在Web.config文件的System.Web.Configuration配置节点中设置ValidationInterval参数。
具体操作步骤如下：```xml<system.web><pages validateRequest="true" validationSettings-unobtrusiveValidationMode="None"validateRequestMode="Inherit" /><httpRuntime targetFramework="4.6.1"requestValidationMode="4.0" /><compilation debug="true" targetFramework="4.6.1" /><authentication mode="Forms"><forms loginUrl="~/Account/Login" timeout="64800" slidingExpiration="true" /></authentication><httpRuntime targetFramework="4.6.1"requestValidationMode="4.0" /><machineKey validationKey="hidden" /><sessionState mode="InProc" cookieless="false" timeout="20" /><pages theme="Theme1" validateRequest="false"viewStateEncryptionMode="Never" /><membership defaultProvider="DefaultMembershipProvider"></membership></system.web>```### 2. 如何使用ValidationInterval参数在设置好ValidationInterval参数之后，我们就可以使用它了。
LoadRunner常遇见报错问题解决方案
LoadRunner常遇见的问题在压力测试过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。
下面结合常用的协议（如Web、Web Services协议）录制的脚本进行回放时出现的问题介绍一下解决的方法。
需要注意的是，回放脚本时出现的错误有时是程序自身的原因导致的，因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。
1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。
错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。
错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner 中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。
解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。
2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。
错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。
错误分析：脚本录制可能采用的是URL-based script方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。
基于源代码的ASPNET HTTP Runtime摘要
Value Engineering 0引言 是灵活的、可扩展的服务器端HTTP 编程的框架，也是一个复杂的使用托管代码来处理Web 请求的引擎。
而HTTP 管道是 的核心基础架构，由一连串的托管对象组成[1]，客户端关于 文件的HTTP 请求正是在这个管道中完成处理，最终生成HTML 文本并返回给客户端。
因此，对HTTP 管道的深入了解，有助于构建功能更强，运行更安全的 应用程序。
基于源代码，本文揭示 HTTP Runtime 的诸多细节，同时须指出的是本文对HTTP 管道的阐述均基于IIS6.0和2.0。
1HTTP 管道之前当第一个关于 文件的HTTP 请求到达IIS 时，此请求被内核模式下的HTTP.SYS 所接收，然后被转发给工作者进程（w3wp.exe ）处理，工作者进程接着加载aspnet_isapi.dll ，并将该请求传递给它。
接下来，aspnet_isapi.dll 装载和初始化.NET CLR ，同时实例化AppManagerAppDomainFactory 对象[2]，并以COM 方式调用AppManagerAppDomainFactory.Create 方法，该方法创建应用程序域（AppDomain ）对象和ISAPIRuntime 对象。
在.NET 的框架类库中，IISAPIRuntime [3]是从ISAPI 扩展到 的一个预定的接口[4]。
其定义如下：[GuidAttribute ("08a2c56f -7c16-41c1-a8be -432917a1a2d1")][InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIUnknown)]public interface IISAPIRuntime {void StartProcessing();void StopProcessing();[return:MarshalAs(UnmanagedType.I4)]int ProcessRequest ([In]IntPtr ecb,[In,MarshalAs(UnmanagedType.I4)]int useProcessModel);void DoGCCollect();}从该接口声明时使用的属性InterfaceTypeAttribute (ComInterfaceType.InterfaceIsIUnknown)可以看到：这个接口是作为IUnknown 派生接口向COM 公开的，这就使得aspnet_isapi.dll 可以以早期绑定方式调用此接口。
服务器处理请求详细过程
服务器处理请求详细过程前⾔ 百度了⼀下才知道，传智的邹⽼师桃李满天下呀，我也是邹⽼师的粉丝，最开始学习页⾯⽣命周期的时候也是看了邹⽼师的视频。
本⼈是参考了以下前辈的作品，本⽂中也参合了本⼈⼼得，绝⾮有意盗版，旨在传播，最主要是⽇后在下也可以参考⼀下，原版出处如下：概念 所谓的页⾯⽣命周期说通俗⼀点，就是浏览器有请求，服务器处理请求并⽣成HTML代码所执⾏的⼀系列的事件⽅法。
概括知识点 1.服务器与浏览器之间的交互：通过Scoket 2.服务器与浏览器交互语法：Http协议 3.服务器与浏览器交互⽬的：获取服务器资源（html,js,img,css..） 4.服务器要做的事就是想尽办法满⾜浏览器的需求，所以⼀旦浏览器请求的是动态页⾯的时候，服务器就要创建页⾯类对象并执⾏⾥⾯的⼀系列的事件与⽅法，并将⽣成的html页⾯代码返回给浏览器. 页⾯⽣命周期事件 1.PreInit:检查IsPostBack 属性创建或重新创建动态控件动态设置主控页动态设置Theme属性读取或者设置配置⽂件属性值设置控件的默认值(UniqueId等）动态设置Master Page 注意：如果请求是回发请求，刚控件的值尚未从视图状态还原，如果在此阶段设置控件属性，则其值可能会在下⼀事件中被重写。
2. Init: 在所有控件都已经初始化且已应⽤所有外观设置后引发，使⽤该事件来读取或初始化控件属性 3.InitComplete: 由Page对象引发。
使⽤该事件来处理要求先完成所有初始化⼯作的任务。
4.PreLoad： 如果需要在Load事件之前对页或者控件执⾏处理，则使⽤该事件。
在Page引发该事件后，它会为⾃⾝和所有控件加载视图状态，然后会处理Request实例包括的任何回发数据。
5.Load: 在Page上调⽤OnLoad事件⽅法，然后以递归⽅式对每个⼦控件执⾏相同操作，如此循环往复，直到加载完页⾯和所有控件为⽌ 6.控件事件： 使⽤这些事件来处理特定控件事件，如Button控件的Click事件或TextBox控件的TextChanged事件 注意：在回发请求中，如果页包含验证程序控件，刚需要在执⾏任何处理之前检查Page和各个验证控件的IsValid属性7.LoadComplete： 对需要加载页上的所有其他控件的任务使⽤该事件 8.PreRender： 在该事件发⽣之前：Page对象会针对每个控件和页调⽤ EnsureChildControls设置了DataSourceID属性的每个数据绑定控件会调⽤DataBind⽅法 页上的每个控件都会发⽣PreRender事件。
详解ASP.NET配置文件Web.config
详解配置⽂件Web.configWeb.config⽂件是⼀个XML⽂本⽂件，它⽤来储存 Web 应⽤程序的配置信息（如最常⽤的设置 Web 应⽤程序的⾝份验证⽅式），它可以出现在应⽤程序的每⼀个⽬录中。
当你通过新建⼀个Web应⽤程序后，默认情况下会在根⽬录⾃动创建⼀个默认的Web.config⽂件，包括默认的配置设置，所有的⼦⽬录都继承它的配置设置。
如果你想修改⼦⽬录的配置设置，你可以在该⼦⽬录下新建⼀个Web.config⽂件。
它可以提供除从⽗⽬录继承的配置信息以外的配置信息，也可以重写或修改⽗⽬录中定义的设置。
在运⾏时对Web.config⽂件的修改不需要重启服务就可以⽣效（注：<processModel> 节例外）。
当然Web.config⽂件是可以扩展的。
你可以⾃定义新配置参数并编写配置节处理程序以对它们进⾏处理。
⼀、web.config配置⽂件（默认的配置设置）以下所有的代码都应该位于<configuration><system.web>和</system.web></configuration>之间，出于学习的⽬的下⾯的⽰例都省略了这段XML标记1、<authentication> 节作⽤：配置 ⾝份验证⽀持（为Windows、Forms、PassPort、None四种）。
该元素只能在计算机、站点或应⽤程序级别声明。
<authentication> 元素必需与<authorization> 节配合使⽤。
⽰例：以下⽰例为基于窗体（Forms）的⾝份验证配置站点，当没有登陆的⽤户访问需要⾝份验证的⽹页，⽹页⾃动跳转到登陆⽹页。
<authentication mode="Forms" ><forms loginUrl="logon.aspx" name=".FormsAuthCookie"/></authentication>其中元素loginUrl表⽰登陆⽹页的名称，name表⽰Cookie名称2、<authorization> 节作⽤：控制对 URL 资源的客户端访问（如允许匿名⽤户访问）。
NET4.0概述
1.窗口移动 2.调用层次结构 3.定位搜索 4.突出显示引用 5.智能感知
4.0开发环境
安装Visual Studio 2010
Visual Studio 2010目前有三个版本：Visual Studio 2010 Professional版本、Visual Studio 2010 Premium 版本和Visual Studio 2010 Ultimate版本，其中前两种用 于个人和小型开发团队采用最新技术开发应用程序和实现有 效的业务目标；第三种为体系结构、设计、开发、数据库开 发以及应用程序测试等多任务的团队提供集成的工具集，在 应用程序生命周期的每个步骤，团队成员都可以继续协作并 利用一个完整的工具集与指南。
4.0框架
4.动态语言运行时（Dynamic Language Runtime，简称DLR） ：动态语言运行时 为像JavaScript、 Ruby、Python甚至 COM组件等动态型语言提供了通用平台。 它将一组适用于动态语言的服务添加到公 共语言运行时。借助于动态语言运行时， 可以更轻松地开发要在.NET 4.0框架上运 行的动态语言，而且向静态类型化语言添 加动态功能也会更容易。
传递Web页面的过程如下： 1. 用户请求页面。 2. 页面将标记动态呈现到浏览器。 3. 用户键入信息或从可用选项中进行选择，然后单击按钮。 4. 页面发送到Web服务器。浏览器执行 HTTP POST 方法，
该方法在 中称为“回发”。在Web服务器上，该 页再次运行。并且可在页上使用用户键入或选择的信息。 5. 页面执行通过编程所要实行的操作。 6. 页面将其自身呈现回浏览器。
(5) 组件加载加载完毕后，“下一步”按钮 被激活。
@Bean注解全解析
@Bean注解全解析随着 SpringBoot 的流⾏，基于注解式开发的热潮逐渐覆盖了基于 XML 纯配置的开发，⽽作为 Spring 中最核⼼的 bean 当然也能够使⽤注解的⽅式进⾏表⽰。
所以本篇就来详细的讨论⼀下作为 Spring 中的 Bean 到底都有哪些⽤法。
@Bean 基础声明Spring 的 @Bean 注解⽤于告诉⽅法，产⽣⼀个 Bean 对象，然后这个 Bean 对象交给 Spring 管理。
产⽣这个 Bean 对象的⽅法 Spring 只会调⽤⼀次，随后这个 Spring 将会将这个 Bean 对象放在⾃⼰的 IOC 容器中。
SpringIOC 容器管理⼀个或者多个 bean，这些 bean 都需要在 @Configuration 注解下进⾏创建，在⼀个⽅法上使⽤ @Bean 注解就表明这个⽅法需要交给 Spring 进⾏管理。
快速搭建⼀个 maven 项⽬并配置好所需要的 Spring 依赖<dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>4.3.13.RELEASE</version></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-beans</artifactId><version>4.3.13.RELEASE</version></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-core</artifactId><version>4.3.13.RELEASE</version></dependency><dependency><groupId>org.springframework</groupId><artifactId>spring-web</artifactId><version>4.3.13.RELEASE</version></dependency>在 src 根⽬录下创建⼀个AppConfig的配置类，这个配置类也就是管理⼀个或多个 bean 的配置类，并在其内部声明⼀个 myBean 的 bean，并创建其对应的实体类@Configurationpublic class AppConfig {// 使⽤@Bean 注解表明myBean需要交给Spring进⾏管理// 未指定bean 的名称，默认采⽤的是 "⽅法名" + "⾸字母⼩写"的配置⽅式@Beanpublic MyBean myBean(){return new MyBean();}}public class MyBean {public MyBean(){System.out.println("MyBean Initializing");}}在对应的 test ⽂件夹下创建⼀个测试类SpringBeanApplicationTests，测试上述代码的正确性public class SpringBeanApplicationTests {public static void main(String[] args) {ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);context.getBean("myBean");}}输出 : MyBean Initializing随着 SpringBoot 的流⾏，我们现在更多采⽤基于注解式的配置从⽽替换掉了基于 XML 的配置，所以本篇⽂章我们主要探讨基于注解的 @Bean 以及和其他注解的使⽤。
http请求处理流程(讲的很清楚)
.NET平台处理HTTP请求.NET平台处理HTTP请求的过程大致如下：1、 IIS得到一个请求；2、查询脚本映射扩展，然后把请求映射到aspnet_isapi.dll文件3、代码进入工作者进程(IIS5里是aspnet_wp.exe；IIS6里是w3wp.exe)，工作者进程也叫辅助进程；4、 .NET运行时被加载；5、非托管代码调用IsapiRuntime.ProcessRequest()方法；6、每一个请求调用一个IsapiWorkerRequest；7、使用WorkerRequest调用HttpRuntime.ProcessRequest()方法；8、通过传递进来的WorkerRequest创建一个HttpContext对象9、通过把上下文对象作为参数传递给HttpApplication.GetApplicationInstance()，然后调用该方法，从应用程序池中获取一个HttpApplication实例；10、调用HttpApplication.Init()，启动管道事件序列，钩住模块和处理器；11、调用HttpApplicaton.ProcessRequest，开始处理请求；12、触发管道事件；13、调用HTTP处理器和ProcessRequest方法；14、把返回的数据输出到管道，触发处理请求后的事件。
当客户端向Web服务器请求一个页面文件时，这个HTTP请求会被inetinfo.exe 进程截获(WWW服务)，它判断文件后缀，如果是*.aspx、*.asmx等，就把这个请求转交给aspnet_isapi.dll，而aspnet_isapi.dll则会通过一个Http PipeLine 的管道，将这个HTTP请求发送给w3wq.exe进程，当这个HTTP请求进入w3wq.exe 进程之后， framework就会通过HttpRuntime来处理这个HTTP请求，处理完毕后将结果返回给客户端。
ASP.NET页面事件执行过程（完整版）
页⾯事件执⾏过程（完整版） 母版页和内容页中的事件母版页和内容页都可以包含控件的事件处理程序。
对于控件⽽⾔，事件是在本地处理的，即内容页中的控件在内容页中引发事件，母版页中的控件在母版页中引发事件。
控件事件不会从内容页发送到母版页。
同样，也不能在内容页中处理来⾃母版页控件的事件。
在某些情况下，内容页和母版页中会引发相同的事件。
例如，两者都引发和事件。
引发事件的⼀般规则是初始化事件从最⾥⾯的控件向最外⾯的控件引发，所有其他事件则从最外⾯的控件向最⾥⾯的控件引发。
请记住，母版页会合并到内容页中并被视为内容页中的⼀个控件，这⼀点⼗分有⽤。
下⾯是母版页与内容页合并后事件的发⽣顺序：1. 母版页控件 Init 事件。
2. 内容控件 Init 事件。
3. 母版页 Init 事件。
4. 内容页 Init 事件。
5. 内容页 Load 事件。
6. 母版页 Load 事件。
7. 内容控件 Load 事件。
8. 内容页 PreRender 事件。
9. 母版页 PreRender 事件。
10. 母版页控件 PreRender 事件。
11. 内容控件 PreRender 事件。
母版页和内容页中的事件顺序对于页⾯开发⼈员并不重要。
但是，如果您创建的事件处理程序取决于某些事件的可⽤性，那么您将发现，了解母版页和内容页中的事件顺序很有帮助。
Page 执⾏中将按照如下顺序激活事件：Page.PreInitPage.InitPage.InitComplitePage.PreLoadPage.LoadPage.LoadCompletePage.PreRenderPage.PreRenderComplete如果页⾯从另⼀个页⾯继承，如BasePage:System.Web.UI.Page，在BasePage中做了⼀些扩展，如权限检查，⽽其他页⾯从BasePage继承，则BasePage和最终Page的事件激活顺序是：UI.PreInitPage.PreInitUI.InitPage.InitUI.InitComplitePage.InitCompliteUI.PreLoadPage.PreLoadUI.LoadPage.LoadUI.LoadCompletePage.LoadCompleteUI.PreRenderPage.PreRenderUI.PreRenderCompletePage.PreRenderComplete如果使⽤了MasterPage，则MasterPage中的事件和ContentPage中的事件按照下⾯顺序激活：ContentPage.PreInitMaster.InitContentPage.InitContentPage.InitCompliteContentPage.PreLoadContentPage.LoadMaster.LoadContentPage.LoadCompleteContentPage.PreRender更进⼀步，如果ContentPage继承BasePage，那么，各事件的执⾏顺序将变成：UI.PreInitContentPage.PreInitMaster.InitUI.InitContentPage.InitUI.InitCompliteContentPage.InitCompliteUI.PreLoadContentPage.PreLoadUI.LoadContentPage.LoadMaster.LoadUI.LoadCompleteContentPage.LoadCompleteUI.PreRenderContentPage.PreRenderMaster.PreRenderUI.PreRenderCompleteContentPage.PreRenderComplete浏览下来发现并不是我现在所学的 1.1，估计应该是 2.0,不过也没有关系，这让我知道了他们有继承时加载的顺序。
.net站的web.config配置说明
.Net站的web.config配置说明一、认识Web.config文件Web.config 文件是一个XML文本文件，它用来储存 Web 应用程序的配置信息（如最常用的设置 Web 应用程序的身份验证方式），它可以出现在应用程序的每一个目录中。
当你通过.NET新建一个Web应用程序后，默认情况下会在根目录自动创建一个默认的Web.config文件，包括默认的配置设置，所有的子目录都继承它的配置设置。
如果你想修改子目录的配置设置，你可以在该子目录下新建一个Web.config文件。
它可以提供除从父目录继承的配置信息以外的配置信息，也可以重写或修改父目录中定义的设置。
(一).Web.Config是以XML文件规范存储,配置文件分为以下格式1.配置节处理程序声明特点：位于配置文件的顶部，包含在configSections标志中。
2.特定应用程序配置特点: 位于appSetting中。
可以定义应用程序的全局常量设置等信息.3.配置节设置特点: 位于system.Web节中，控制运行时的行为.4.配置节组特点: 用sectionGroup标记，可以自定义分组，可以放到configSections内部或其它sectionGroup标记的内部.(二).配置节的每一节1.configuration节根元素，其它节都是在它的内部.2.appSetting节此节用于定义应用程序设置项。
对一些不确定设置，还可以让用户根据自己实际情况自己设置用法:I.appSettingsadd key="Conntction" value="server=192.168.85.66;userid=sa;password=;database=Info;"/ appSettings定义了一个连接字符串常量，并且在实际应用时可以修改连接字符串，不用修改程式代码. II.appSettingsadd key="ErrPage" value="Error.aspx"/appSettings定义了一个错误重定向页面.pilation节格式:compilationdefaultLanguage="c#"debug="true"/I.default language: 定义后台代码语言,可以选择C#和两种语言.IIdebug : 为true时，启动aspx调试；为false不启动aspx调试，因而可以提高应用程序运行时的性能。
常见的HTTP接口超时问题出现原因及解决办法
常见的HTTP接口超时问题出现原因及解决办法HTTP接口超时问题是指在HTTP请求发送到服务器后，由于等待服务器响应的时间超过了预设的超时时间，导致请求被中断。
以下是可能导致HTTP接口超时问题的原因和解决方法：网络延迟或不稳定：网络延迟或不稳定可能导致请求在传输过程中耗费的时间超过了预设的超时时间。
解决方法是优化网络环境，确保网络连接稳定。
服务器负载过高：如果服务器同时处理大量请求，可能会导致响应时间延长，超出了客户端的超时时间。
解决方法是优化服务器性能，提升处理请求的能力。
请求的数据量过大：传输大量数据可能导致请求在传输过程中耗费的时间过长。
解决方法是减少请求的数据量，例如通过分页或压缩数据。
服务器未正确配置：服务器的配置问题可能导致响应时间过长。
解决方法是检查服务器的配置，确保服务器能够正确处理请求并快速响应。
客户端的超时时间设置过短：如果客户端的超时时间设置得过短，可能导致请求在等待服务器响应时超时。
解决方法是合理设置客户端的超时时间，根据实际情况进行调整。
防火墙或安全组策略：防火墙或安全组策略可能限制了客户端与服务器之间的通信，导致请求超时。
解决方法是检查防火墙或安全组策略，确保它们允许正常的通信。
路由问题：路由问题可能导致请求在传输过程中耗费的时间过长。
解决方法是检查路由配置，确保请求能够快速到达服务器。
解决HTTP接口超时问题需要根据具体情况进行分析和排查。
在开发过程中，需要注意网络环境、服务器性能、请求数据量、服务器配置、客户端超时时间、防火墙和安全组策略以及路由配置等方面的问题，以确保HTTP接口的正常运行。
解除HTTP接口超时问题可以通过以下几个方面进行解决：检查服务器地址是否可达：如果发现客户端发出的HTTP请求超时，可以通过ping检查服务器地址是否可达。
如果服务器地址不可达，则可以尝试重新连接服务器。
检查网络连接是否正常：如果发现客户端发出的HTTP请求超时，可以检查客户端与服务器之间的网络连接是否正常。
ASP.NET页面请求超时时间设置多种方法
页⾯请求超时时间设置多种⽅法页⾯请求超时时间（页⾯后台程序执⾏时间）默认值为110秒(在 .NET Framework 1.0 版和 1.1 版中，默认值为 90 秒)即：Server.ScriptTimeout = 110（HttpServerUtility.ScriptTimeout = 110）System.Web.Configuration.HttpRuntimeSection().ExecutionTimeout.ToString() =00:01:50（110 秒）⽅法⼀：设置 Server.ScriptTimeout 的值注意：设置的值必须⼤于90，否则不会⽣效，请求超时值依然是90秒 (⽹上流传的说法，经验证错误）只有当compilation元素中的调试属性为False时，此超时属性才适⽤（true：ScriptTimeOut=30000000）。
若要避免在调试期间关闭应⽤程序，请不要将此超时属性设置为较⼤值。
<span style="font-family: 'Microsoft YaHei';">//单位秒 Server.ScriptTimeout = 60;</span>⽅法⼆：Web.config 配置httpRuntime executionTimeout （单位秒）注意：只有当compilation元素中的调试属性为False时，此超时属性才适⽤（true：ScriptTimeOut=30000000）。
若要避免在调试期间关闭应⽤程序，请不要将此超时属性设置为较⼤值。
httpRuntime executionTimeout 的设置可修改Server.ScriptTimeout的值，使⽤ScriptTimeout属性以编程⽅式对超时值进⾏的设置优先于Web.config设置。
<span style="font-family: 'Microsoft YaHei';"><system.web><compilation debug="false" targetFramework="4.0" /><!-- 设置为600秒 Server.ScriptTimeout = 600 --><httpRuntime executionTimeout="600"/></system.web></span>复制代码代码如下:System.Web.Configuration.HttpRuntimeSection configSection = new System.Web.Configuration.HttpRuntimeSection();configSection.ExecutionTimeout = TimeSpan.FromSeconds(100);⽅法四：IIS配置修改脚本超时值这个未确定⽹站→⾼级设置：⼀样未确定应⽤程序池→⾼级设置：注意：如果页⾯使⽤了 UpdatePanel，UpdatePanel 内部的请求分以下两种情况：①设置的超时值 >=90秒，UpdatePanel 内部的请求超时值将变为 90 秒！②设置的超时值 <90秒，UpdatePanel 内部的请求超时值将变为所设置的值！下图Server.ScriptTimeout= 5 秒，点击UpdatePanel 内部的按钮，Thread.Sleep(20 * 1000) 秒，请求超时，但是页⾯看不到报错信息！⽽点击UpdatePanel 外部的按钮，则会报如图1的 “请求超时”的错误信息！下图Server.ScriptTimeout= 100 秒，点击UpdatePanel 内部的按钮，Thread.Sleep(95 * 1000)//停⽌95秒; 实际上到90秒就超时了（如下⾯第⼆图）⽽点击UpdatePanel 外部的按钮，Thread.Sleep(95 * 1000)//停⽌95秒，请求成功！=======================================================================================================================全局超时时间服务器上如果有多个⽹站，希望统⼀设置⼀下超时时间，则需要设置 Machine.config ⽂件中的 ExecutionTimeout 属性值。
ASP.NET文件上传大小的限制解决方案
⽂件上传⼤⼩的限制解决⽅案我们⼤家都知道为我们提供了⽂件上传FileUpload，默认情况下可上传的最⼤⽂件为4M，如果要改变可上传⽂件⼤⼩限制，那么我们可以在web.config中的httpRuntime元素中添加maxRequestLength属性设置⼤⼩，同时为了⽀持⼤⽂件上传超时可以添加executionTimeout属性设置超时时间。
⽹上有很多这样的例⼦，但实际情况是否是这样吗？<httpRuntime maxRequestLength="" executionTimeout=""/>测试环境IIS 7.5、.NET 3.5 sp1测试页⾯UploadFile.aspx<%@ Page Language="C#" AutoEventWireup="true" CodeFile="UploadFile.aspx.cs" Inherits="UploadFile" %><!DOCTYPE html><html xmlns="/1999/xhtml"><head runat="server"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/><title></title></head><body><form id="form1" runat="server"><div><asp:FileUpload ID="FileUpload1" runat="server" /><asp:Button ID="Button1" runat="server" Text="Button" /></div></form></body></html>测试页⾯UploadFile.aspx.csusing System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;public partial class UploadFile : System.Web.UI.Page{protected void Page_Load(object sender, EventArgs e){if (FileUpload1.FileContent != null){FileUpload1.SaveAs(Server.MapPath("/Files/"+FileUpload1.FileName));}}}实际测试1.上传⼩于4M的⽂件选择2.7M的pdf⽂件上传上传提⽰成功2. 上传⼤于4M的⽂件选择上传4.3M的pdf⽂件上传后报黄页3. 修改web.config⽂件，设置可上传⽂件⼤⼩限制修改web.config，增⼤可上传⽂件的⼤⼩限制，增⼤执⾏时间限制<httpRuntime maxRequestLength="2048000" executionTimeout="600"/>重新选择刚才4.3M的pdf⽂件，重新上传上传成功4. 上传⼤于30M的的⽂件碰到这个问题的实际环境是我们使⽤了第三⽅的上传⽂件组件，通过js调⽤第三⽅的ActiveX控件上传⽂件，修改web.config后上传⼤于30M 的⽂件的时候，报了如下错误查看windows系统⽇志，可以看到如下的⽇志错误，看到异常信息，我们可以猜测到是请求超长，但是我们设置了最⼤请求长度了啊，⽽且远远要⼤于30M。
timeoutTimeout时间已到.在操作完成之前超时时间已过或服务器未响应
timeoutTimeout时间已到.在操作完成之前超时时间已过或服务器未响应Timeout时间已到.在操作完成之前超时时间已过或服务器未响应问题在使⽤开发的应⽤程序查询数据的时候，遇到页⾯请求时间过长且返回"Timeout时间已到。
在操作完成之间超时时间已过或服务器未响应"的情况分析造成这⼀问题的原因⼤概有以下⼏点：请求超时2.Webservice请求超时3.IIS请求超时4.数据库连接超时凭经验判断，应当是数据库连接超时造成，根据在⽹上找到的解决⽅法，进⾏了以下尝试连接字符串中添加Connect Timeout在数据库连接字符串后⾯添加Connect Timeout=500（连接超时时间设为500秒）SqlConnection con = new SqlConnection("server=.;database=myDB;uid=sa;pwd=password;Connect Timeout=500")运⾏查询后，不到30秒，仍然返回Timeout超时，问题未解决设置Command对象属性CommandTimeoutSqlCommand cmd = new SqlCommand();mandTimeout = 180;运⾏，可以解决Command的执⾏超时问题，这⾥设置的时间的180秒，可根据需要设置，如果过长，也可设置为0，设置为0时表⽰不限制时间，此属性值需慎⽤。
还需要在Web.config配置⽂件中设置http请求运⾏时限间<system.web><httpRuntime maxRequestLength="102400" executionTimeout="720" /></system.web>这⾥设置的为720秒，前⾯的属性maxRequestLength⼀般⽤于⽤户上传⽂件限制⼤⼩！默认⼀般为4096 KB (4 MB)。
一个请求的生命周期（HTTP请求过程详解、TCPIP五层网络模型）
⼀个请求的⽣命周期（HTTP请求过程详解、TCPIP五层⽹络模型）⼀个请求的⽣命周期前⾔：当我们从电脑上去访问⼀个⽹址时，究竟发⽣了什么？这个问题可能是⾃⼰思考或者⾯试的时候问到，这⾥我们以访问百度⾸页为例，进⾏⼀个全⾯的HTTP请求分析。
核⼼概念计算机⽹络核⼼结构，就是TCP/IP五层⽹络模型（OSI七层模型是将应⽤层分为了三层）以及，每⼀层对应的协议始于本地键盘输⼊：你要访问，⾃然需要在浏览器地址栏中使⽤键盘输⼊（正常情况下），这个过程就涉及到输⼊设备与计算机的交互了，这个属于物理层，这⾥就不探讨了（==其实是我不会）请求域名：⾸先你访问的是，并不带域名，所以浏览器会⾃动补全协议头。
但是我们知道，很多时候域名会有http和https，它俩的默认端⼝⼀个是80，⼀个是443，在这⾥，⼀般都是对应域名的⽹站做了端⼝转发，http协议实现了HSTS机制来使得重定向到HTTPS下的域名。
所以HTTP到HTTPS这个过程是服务器来完成的，⾄于浏览器的默认端⼝⼀直是80端⼝路由转发IP查找：⽬前我们只知道了带协议类型的域名，那么是如何到具体的服务器的呢？我们知道，对于因特⽹内每个公有地址IP都是唯⼀的（局域⽹内不⼀定），域名相当于IP的别名，因为我们⽆法去记住⼀⼤堆⽆意义的IP地址，但如果⽤⼀堆有意义的字母组成，⼤家就能快速访问对应⽹站。
DNS解析：通过域名去查找IP，先从本地缓存查找，其中本地的hosts⽂件也绑定了对应IP，若在本机中⽆法查到，那么就会去请求本地区域的域名服务器（通常是你对应的⽹络运营商如移动），这个通过⽹络设置中的LDNS去查找，如果还是没有命中的话，那么就去根域名服务器查找，这⾥有所有因特⽹上可访问的域名和IP对应信息（根域名服务器全球共13台）。
⾄少到了这⾥，我们肯定能查找对应的IP了，要不就是这个域名不对。
路由转发：然后我们通过⽹卡、路由器、交换机等设备，实现两个IP地址之间的通信。
性能测试问题解决方法-19种情况
一、Error -27727: Step download timeout (120 seconds)has expired whendownloading resource(s). Set the “Resource Page Timeout is aWarning” Run-Time Setting to Yes/No to have this message as awarning/error, respectively处理方法：Run-Time Setting ------ Internet Protocol ------ Preferences------Option ------ Step download timeout(sec)改为32000A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大或多二、错误现象：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。
错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。
解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在"Runtime Setting">"Internet Protocol：Preferences">"Advanced"区域中设置一个"winlnet replay instead of sockets"选项，再回放是否成功。
三、Action.c(7): Error -27791: Server “192.168.1.77″ has shut down the connection prematurely解决方案如下：1、应用服务器死掉。
Http请求超时的一种处理方法
Http请求超时的⼀种处理⽅法URLConnection类常见的超时处理就是调⽤其setConnectTimeout和setReadTimeout⽅法：1. setConnectTimeout：设置连接主机超时（单位：毫秒）2. setReadTimeout：设置从主机读取数据超时（单位：毫秒）还有⼀种⽐较另类的就是利⽤java Object对象的wait()和notify()、notifyAll()⽅法，利⽤线程的等待和通知机制处理urlConnection的超时，下⾯直接贴代码：public class HttpConnProcessThread implements Runnable {public boolean isStop = false;public boolean readOK = false;private HttpURLConnection reqConnection = null;public Thread readingThread;private int readLen;private String msg = null;private String reqMethod;private byte[] data;/*** ReadThread constructor comment.*/public HttpConnProcessThread(HttpURLConnection reqConnection, String msg, String reqMethod ) {super();this.reqConnection = reqConnection;this.msg = msg;this.reqMethod = reqMethod;}public void run() {InputStream input = null;OutputStream output = null;try{//reqConnection.connect();output = reqConnection.getOutputStream();if ("post".equalsIgnoreCase(reqMethod) && msg != null && msg.length() >0){output.write(msg.getBytes());output.close();output = null;}// 处理HTTP响应的返回状态信息int responseCode = reqConnection.getResponseCode();// 响应的代码if( responseCode != 200 )System.out.println("connect failed! responseCode = " + responseCode + " msg=" + reqConnection.getResponseMessage());input = reqConnection.getInputStream();int len;byte[] buf = new byte[2048];readLen = 0;ByteArrayOutputStream outStream = new ByteArrayOutputStream(); // 读取inputStreamwhile (!isStop){len = input.read(buf);if (len <= 0){this.readOK = true;input.close();data=outStream.toByteArray();break;}outStream.write(buf, 0, len);readLen += len;}}catch( IOException ie){}catch(Exception e){}finally{try{reqConnection.disconnect();if( input != null )input.close();if( output != null )output.close();//唤醒线程，跳出等待wakeUp();}catch(Exception e){}}}public String getMessage(){if (!readOK) //超时{return "";}if (readLen <= 0) {return "";}return new String(data, 0, readLen);}public void startUp() {this.readingThread = new Thread(this);readingThread.start();}//唤醒线程，不再等待private synchronized void wakeUp() {notifyAll();}public synchronized void waitForData(int timeout){try {//指定超时时间，等待connection响应wait(timeout);}catch (Exception e){}if (!readOK){isStop = true;try{//中断线程if( readingThread.isAlive() )readingThread.interrupt();}catch(Exception e){}}}public static main(String[] args){String msg="";URL reqUrl = new URL("http://127.0.0.1:8080/");// 建⽴URLConnection连接reqConnection = (HttpURLConnection) reqUrl.openConnection();HttpConnProcessThread rec = new HttpConnProcessThread(reqConnection, msg, "post" ); rec.startUp(); // 如果顺利连接到并读完数据，则跳出等待，否则等待超时rec.waitForData(2000);String retMessage = rec.getMessage();}}。
处理“System.Web.HttpException：超过了最大请求长度”
在通常（不局限于此）在上传文件大于默认的4M 或 Web.config 的的配置时会抛出此异常；
Web.config 配置：
<configuration> <system.web> <httpRuntime maxRequestLength="4096" executionTimeout="3600" /> </system.web> <configuration>
//当前请求上下文的HttpApplication实例 //HttpContext context = ((HttpApplication)sender).Context;
//判断请求的内容长度是否超过了设置的字节数 if (Request.ContentLength > maxRequestLength) {
#region 不理解这些代码存在的意义 /* //得到服务对象 IServiceProvider provider = (IServiceProvider)context; HttpWorkerRequest workerRequest = (HttpWorkerRequest)provider.GetService(typeof(HttpWorkerRequest));
//从配置文件里得到配置的允许上传的文件大小 HttpRuntimeSection runTime = (HttpRuntimeSection)WebConfigurationManager.GetSection("system.web/httpRuntime");
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
IIS 5 的 请求处理过程
对图的解释：
IIS 5.x 一个显著的特征就是Web Server 和真正的 Application 的分离。
作为Web Server
的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的 Application aspnet_wp 的Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。
IIS6 的 请求处理过程
对图的解释：
IIS 5.x 是通过InetInfo.exe 监听Request 并把Request分发到Work Process。
换句话说，在IIS 5.x中对
Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：
注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。
一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。
Kernel Mode的代码允许访问所有系统内存和所有CPU指令。
在User Mode下，http.sys接收到一个基于aspx 的http request，然后它会根据IIS中的Metabase 查看该基于该Request 的Application 属于哪个Application Pool，如果该Application Pool不存在，则创建之。
否则直接将request 发到对应Application Pool 的Queue中。
每个Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。
在IIS Metabase 中维护着Application Pool 和worker process的Mapping。
WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。
在worker process 初始化的时候，加载
ISAPI， ISAPI 进而加载CLR。
最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的Create方法为Application 创建一个Application Domain；通过ISAPIRuntime 的ProcessRequest处理Request，进而将流程进入到 Http Runtime Pipeline。
IIS 7的 请求处理过程
IIS7 站点启动并处理请求的步骤如下图：
步骤1 到6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。
上图的8个步骤分别如下：
1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。
2、HTTP.sys contacts WAS to obtain information from the configuration store.
3、WAS 向配置存储中心请求配置信息。
applicationHost.config。
4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。
5、WWW 服务使用配置信息去配置HTTP.sys 处理策略。
6、WAS starts a worker process for the application pool to which the request was made.
7、The worker process processes the request and returns a response to HTTP.sys.
8、客户端接受到处理结果信息。
W3WP.exe 进程中又是如果处理得呢？？IIS 7 的应用程序池的托管管道模式分两种：经典和集成。
这两种模式下处理策略各不相通。
本文作者：郭红俊/ghj
IIS 6 以及IIS7 经典模式的托管管道的架构
在IIS7之前， 是以IIS ISAPI extension 的方式外加到IIS，其实包括ASP 以及PHP，也都以相同的方式配置（PHP 在IIS 采用了两种配置方式，除了IIS ISAPI extension 的方式，也包括了CGI 的方式，系统管理者能选择PHP 程序的执行方式），因此客户端对IIS 的HTTP 请求会先经由IIS 处理，然后IIS 根据要求的内容类型，如果是HTML 静态网页就由IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的IIS ISAPI extension；如果要求的内容类型是，就分派给负责处理 的IIS ISAPI extension，也就是aspnet_isapi.dll。
下图是这个架构的示意图。
IIS7 应用程序池的托管管道模式经典模式也是这样的工作原理。
这种模式是兼容IIS 6 的方式，以减少升级的成本。
IIS6 的执行架构图，以及IIS7应用程序池配置成经典模式的执行架构图
IIS7 应用程序池的托管管道模式集成模式
而IIS 7 完全整合.NET 之后，架构的处理顺序有了很大的不同（如下图），最主要的原因就是 从IIS 插件（ISAPI extension）的角色，进入了IIS 核心，而且也能以 模块负责处理IIS 7 的诸多类型要求。
这些 模块不只能处理 网页程序，也能处理其他如ASP 程序、PHP 程序或静态HTML 网页，也因为 的诸多功能已经成为IIS 7 的一部份，因此ASP 程序、PHP 程序或静态HTML 网页等类型的要求，也能使用像是Forms认证（Forms Authentication）或输出缓存（Output Cache）等 2.0 的功能（但须修改IIS 7 的设定值）。
也因为IIS 7 允许自行以 API 开发并加入模块，因此 网页开发人员将更容易扩充IIS 7 和网站应用程序的功能，甚至能自行以.NET 编写管理IIS 7 的程序（例如以程控IIS 7 以建置网站或虚拟目录）。
IIS 7 的执行架构图（集成托管信道模式下的架构）
源文档 </ghj/archive/2008/07/25/115200.aspx>
aspx页面生命周期2010年7月12日
11:48。