SESSION超时时间过短的解决
ASP（Active Server Pages）技术的Session对象用于存储用户在对话期间的私有信息。当前用户的Session对象中定义的变量和对象能在页面之间共享，但是不能为应用中其他用户所访问，因此在用ASP开发网络应用程序时，可以利用Session对象保存和跟踪用户的状态信息。
Session对象有一个十分重要的属性：Timeout，它用于设置在会话资源被释放前，会话对象所能保持非活动状态的时间（默认值为20分钟）。当Timeout属性设置的时间值耗尽后，会话资源将被释放。通过Timeout属性破坏Session对象，避免了Session对象在服务器中无限制地产生，保护了服务器资源。
1、设置网站的应用程序配置2、设置ASP.NET中的配置，修改webconfig文件。（也可以通过代码添加）3、Session储存的位置绝对不在客户端。Session储存方式有三种，可在web.config中设置。
InProc模式，这种模式下Session保存在ASP.NET的进程内，是一个内部容器，在同一个应用程序目录是共享的，但是如果这个进程被Web服务器回收，则Session就会丢失，所以这种模式很不稳定。
StateServer模式，这种模式下Session被保存在一个Windows Service的进程内，Windows Service的进程比ASP.NET的进程稳定得多，只要开启这个服务的电脑不当机，一般来说都是比较稳定的。
SQL Server模式，这种模式就更进一步，将Session保存到了数据库中，通过牺牲效率换取稳定。也可通过ASP.NET配置设置4、存储的类型和大小？
一般来说，InProc模式下，Session对储存的对象没有任何限制。而在StateServer和SQL Server模式中，由于Session需要跨进程保持，所以要求所储存对象的类型必须是可序列化的。虽然Session对所储存的数据大小没有什么限制，但不建议在Session中储存太多的东西。5、生命周期是怎么样的？
正常情况下Session在新的客户端第一次访问页面时创建，在超过超时时间没有任何页面访问后销毁。6、常见的访问方法
一般来说Session这种公用容器需要为期专门撰写访问类，而不应直接访问。
一个简单的访问类可能看起来是这样的：public MyContext
{
public static MyContext Current
{
get { return HttpContext.Current.Session["hnop"] as MyContext; }
set { HttpContext.Current.Session["hnop"] = value; }
}
}
7、比较
Session的特点很突出，就是他与客户端有关，一般来说只要客户端不关闭浏览器，那么他访问的所有的页面所获得的都是同一个Session容器。我们可以往Session中放入用户相关的信息，如登陆信息。但要注意的是，Session是一个公共容器，所以他里面的信息可以被任何运行在服务器上的代码所修改。
===========================================================================================================
ASP.Net中的Session
如果用户关闭了Cookie，Session的值一样也可以被保存。
config.web文件进行一些配制，因为在其中找到关于Session的设置文本，如:
<sessionstate cookieless="false" />
把cookieless="false" 改成cookieless="true" ，那么以后Session就不储存在cookies中了，而在储存在URL中。
Session还能在另外一台主机上保持：把localhost改成您要的主机
<sessionstate inproc="false" server="localhost" port="42424" />
===========================================================================================================
摘录自：http://www.lslnet.com/linux/docs/linux-4141.htm
Application状态为应用程序提供了一个全局的状态。所有客户都可以使用该状态。从设计的角度来说，我们通常用Application来存储一些标准的数据。同时，我们在使用它时要注意避免性能的降低，存储的数据尽可能提供给客户只读的功能。
我们可以使用HttpApplication类的Application属性来访问Application状态，它返回一个HttpApplicationState类的实例。这个类是一个对象集合，可以存储任何类型的数据，并以键/值对的形式存储。一旦数据被存储到状态后，就不会删除，除非应用程序重新启动或者被终止或回收。
我们可以在Global.asax的Application_Start函数中存储数据： void Application_Start(object src, EventArgs e) { int exp = 0; // population of dataset from ADO.NET query not shown // Cache DataSet reference Application["Experiment"] = exp; }
现在你可以在任意页面下使用它：
private void Page_Load(object src, EventArgs e) { int expr = Int32.Parse((Application["Experiment"])); }
由于Application状态对于所有客户都是共享的，如果客户只是读取该数据，则没有什么问题，一旦要进行写操作，就不能保证线程的安全以及出现同步争用的问题。我们可以使用HttpApplicationStateLock类，它派生于ReadWriteObjectLock类，它提供了读/写锁的两种属性。在ASP.Net下，隐式地调用了AcquireWrite（）和AcquireRead（）方法以保证避免上面的问题。当然，我们也可以显示地使用Lock（）和Unlock（）：
private void Page_Load(object sender, System.EventArgs e) { Application.Lock(); int expr = Int32.Parse((Application["Experiment"])); if (expr>=something) { //do something } Else { //do something else } Application.UnLock(); //Some other thing goes here }
session,cookie,view状态都是用来保存客户端信息的。它们之间又有什么区别呢？
Session状态是在客户登录的时候创建的，它保存了客户特定的信息，并以Session ID来标识。当一个新客户访问应用程序时，先生成一个新的Session ID（或是Session Key），并为同一个客户接下来的请求创建联系。你可以在Session State中存储任意类型的数据，作为你的应用，状态被同一个进程和AppDomain（App域）维护。Session State的特点是为每一个特定的客户创建状态以维护客户的信息，这些状态信息存储在服务器端的默认的会话状态配置中。
Session(“Value”) = expr ; // Storing the data into session object SomeFunction() { int expr = Int32.Parse(Session(“Value”));//Accessing from it if (expr>=something) { //do something } Else { //do something else } //Some other thing goes here }
既然Session State针对特定的客户建立，通过它来识别客户的请求。Asp.Net提供了一种加密机制和编码算法生成自己的Session Key。这是非常必要的，因为知道了你的Session Key，就有权限访问指定的页面了。
在ASP.Net中生成Session Key的方法：
byte[] sessionkey = new byte[15];
//Generates a random number RNGCryptoServiceProvider rngkey = new RNGCryptoServiceProvider (); rngkey.GetBytes (sessionkey); string clientsessionKey = SessionId.Encode (sessionkey);
但是Session和客户端的Cookie是有关的，当客户关掉Cookie时，Session就失效了。不过在ASP.Net 中可以在web.config中修改设置，使Session的传递脱离Cookie。方法是：
对于Cookie大家并不陌生，每个Cookie存储了多个名/值对，我们可以通过HttpCookie类的值集合来访问它，也可以间接地通过类所提供的索引器访问。Cookie在ASP.Net下的使用： protected void Page_Load(Object sender, EventArgs E) { int expr = 0; if (Request.Cookies["Expr"] == null) { // "Expr" cookie not set, set with this response HttpCookie cokExpr = new HttpCookie("Expr"); cokExpr.Value = exprTextBox.Text; Response.Cookies.Add(cokExpr); expr = Convert.ToInt32(exprTextBox.Text); } else { // use existing cookie value... expr = Convert.ToInt32(Request.Cookies["Expr"].Value); } // use expr to customize page }
由于Cookie存储的信息是放到客户端的，用户在访问服务器端页面时，必然在客户端和服务器端之间频繁交换信息，影响了程序的性能。而Session由于存储在服务器内存中，因此不存在这个问题。不过，Session存储的信息是临时的，用户一旦关闭浏览器，状态即失去。而Cookie则相反。
至于View State，主要是指控件和页面的状态信息，它以_VIEWSTATE值传递给服务器端。有兴趣的可以看我另外一篇文章：ASP.Net中控件的EnableViewState属性
Application、Session和Cookie，可以借用Carfield的总结：
COOKIE 是本地文件，是 40 大盗在阿里巴巴家做的记号，或者是送牛奶的人在你家门口钉的箱子。
SESSION 是服务器端内存，是你洗澡时浴池发给你的钥匙。自己专用，可以开自己的好多箱子。
APPLICATION 是公共浴池。在这里能看见所有人，包括 ppmm 哦：）。
IIS6,SESSION超时时间过短的解决。通常在主目录->配置->应用程序选项重设置会话时间，默认20，单位分钟。另外还可以修改配置文件METABASE.XML的ASPSESSIONTIMEOUT项实现。但这次没有起作用。去掉了站点本身的可能，最后把目标放在应用程序池上。打开网站对应的应用程序池属性，将WEB园数量改为1。重启IIS后，session正常。
2
IIS6下面默认SESSION的超时时间是20秒，造成一些程度认证信息丢失，检查发现这是由于META-BA**.*ML的设置里面ASPSESSIONTIMEOUT="20"引起的。一般可以考虑改为900或者1200。
这个设置文件在WINDOWS\SYSTEM32\INETSRV下面。
注意修改之前需要停掉IISADMIN服务。改完了重启W3SVC就可以用了。
3
应用程序池DefaultAppPool关闭超时错误2007年03月15日 12:15今天服务器产生“应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '2068'。”的错误，导致iis处于假死状态，而这样的情况在前期数量少的网站情况下没有发生。后来通过搜索相关网站，才了解是IIS应用程序池的设置问题。解决方法如下：
右击应用程序池DefaultAppPool，选取属性：
一、回收
1、回收工作进程（分钟）：选中，值为1740
2、回收工作进程（请求数目）：不选（原先设置为35000）
3、在下列时间回收工作进程：不填
4、消耗太多内存时回收工作进程：全不选。（2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题，导致iis假死不响应）
二、性能
只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1（默认）。注意web园这里一定要保持默认，如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。
原来的请求队列限制为4000，现在无限制。
三、运行状况
前两项都起用，是原来的默认设置。启动时间限制90秒，关闭时间限制180秒。
“关闭时间限制180秒”是必须的，因为进程关闭的时间，原来为90秒限制,是默认值，如果进程关闭时间超过90秒，则认为超时，从而出现：进程关闭时间超过了限制 日志，所以，适当延长这个时间，可以避免这种错误
.Net WebService(也包括一般意义的 HttpWebRequest) 超时设置
.Net WebService(也包括一般意义的 HttpWebRequest) 超时设置
1. 服务器端设置超时
在 web.config 的 system.web 里添加如下配置项:
< httpRuntime
executionTimeout="30"
/>
以上时间单位是秒.
记得要把 web.config 的 debug 模式关闭:
< compilation
defaultLanguage="c#"
debug="false"
/>
如果 debug 模式没有关闭, executionTimeout 会被忽略. 这时候, 如果应用是在单步跟踪的模式下, 根据经验, 超时时间大约是 90 秒(在 machine.config 里设置的, 我猜的^_^), 如果不是在单步跟踪的模式下, 超时时间可能是 20 分钟(也是我猜的, 因为其 session 的缺省超时时间是 20 分钟, 哈). 我懒得找微软的文档作进一步的求证了, 反正我用不着知道 debug 模式下的确切超时时间.
2. 客户端设置超时
在 WebService 的客户端代理程序(用 wsdl.exe 生成)里设置 Request 超时时间, 单位是毫秒:
protected override WebRequest GetWebRequest(Uri uri)
{
HttpWebRequest wr = (HttpWebRequest)base.GetWebRequest( uri );
wr.Timeout = 30*1000;
return wr;
}
服务器上发行后不能起作用的设置：
<sessionState mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
cookieless="false"
timeout="30" />
服务器上发行后能够起作用的设置：
<sessionState mode="InProc"
cookieless="false"
timeout="30" />
因为看了下面的文章后，知道stateConnectionString和sqlConnectionString是当设置mode的方式是stateServer和sqlServer的时候，必须的选项，但是当mode配置为InProc时，并不是必须的。stateConnectionString和sqlConnectionString中的127.0.0.1是默认的设置，但是当是远程服务器的时候，需要更改才能其效果，但是最好最简单的方法，也是平时最常用的方法，就是我在第二个配置中的写法。
