1.理解Session State模式存储位置InProc：session在服务器中以活动对象方式存储（aspnet_wp.exe）StateServer: session被序列化并保存在单独的aspnet_state.exe的内存中。StateServer能够运行在另一台服务器上SQLServer: session被序列化并保存在SQL Server中性能：InProc：最快，但是session数据越多，web服务器上消耗的内存也越多，它可能影响性能。StateServer：当存储基本类型（如string,integer等）数据时，在同一个测试环境中它比InProc慢15%。如果你存储大量对象，序列化和反序列化可能影响到性能SQLServer：当存储基本类型（如string,integer等）数据时，在同一个测试环境中它比InProc慢25%。它也有与StateServer一样的序列化性能问题。关于Out-of-Proc（OOP，非InProc）模式的性能提示如果你使用OOP模式（即StateServer或SQLServer），session state中的序列化和反序列化对象将成为你的主要性能消耗之一。对于基本类型，ASP.NET通过一种内部优化方法来完成序列化和反序列化。（基本类型包括所有的数字类型(如Int, Byte, Decimal,String, DateTime, TimeSpan, Guid, IntPtr和UIntPtr等)）如果你有一个session变量（如一个ArrayList对象），且它不是一个基本类型，ASP.NET将使用BinaryFormatter来进行序列化和反序列化，那可能会相对慢一些。所以出于性能考虑，最好使用上面列出的基本类型来存储所有的session state数据。例如，如果你需要存储两个东西，名字和地址，在session state中你既可以(方法a)使用两个string session变量来存储它们，也可以（方法b）创建一个内含两个string的类来保存它们，然后把这个类对象保存在一个session变量中。出于性能考虑，你应该选择方法a。为了进一步理解这个主题，请看FAQ中的一个问题：“序列化和反序列化如何在SqlServer和StateServer模式下工作”健壮性InProc：如果工作者进程（aspnet_wp.exe）进行资源回收或者应用程序域(appdomain)重启动，session state就会丢失。这是因为session state是保存在一个应用程序域的内存空间中的。对配置文件（如web.config和machine.config）的修改或者\bin目录的任何改变（例如在你使用VS编译应用程序后产生了一个新的dll）都可能引起重启动，详细请见KB324772。在1.0中，也有一个bug可能引起工作者进程重启动，但这个bug在1.1中已经修复，见KB321792。如果你使用的是IIS6.0，你可以在IIS Manager中找到Application Pools/DefaultAppPool，其中可以看到回收(Recycling)选项卡与性能(Performace)选项卡中是否有引起IIS工作者进程(w3svc.exe)停止工作的参数。StateServer：解决了InProc模式的session state丢失问题。允许一个webfarm在中央服务器中存储session。只能在State Server上出现失败。SQLServer：与StateServer相似。session state的数据在SQL Server重启后仍然保留着，你也可以按照KB311209的步骤使用SQL server failover cluster警告InProc：它不能在web garden模式下工作，因为在这个模式下会有多个aspnet_wp.exe在同一台机器上运行。建议在使用web garden使切换到State Server或SQL Server。仅在InProc模式下支持Session_End事件。StateServer- 在web farm中，请确认在所有的web服务器上有相同的<machineKey>。KB313091描述了如何设置它。- 请确保你的对象是可序列化的。详见KB312112- 为了在web farm中的不同web服务器上维护session state，IIS Metabase中的网站应用程序路径（如\LM\W3SVC\2）应该在所有的服务器上保持一致（大小写敏感）。详见KB325056SQLServer- 在1.0中有一个bug，如果你在连接字符串中指定integrity security（如"trusted_connection=true"或 "integrated security=sspi"），且你打开了asp.net的身份模拟，它将不会工作。这个问题在KB324479中有描述，不幸的是这份文档中的描述和原因部分是错误的。不过已经有一个QFE fix对它作了修复，这个fix将包含在1.0 sp3中。这个问题在1.1中已经修复了。- 请确认你的对象是可序列化的，否则你的请求可能被挂住，详见KB312112。SQLServer模式的挂起问题已经在1.1中修复，KB324479的QFE fix也修复了这个问题。1.0 sp3也对这个问题作了修复。- 为了在web farm中的不同web服务器上维护session state，IIS Metabase中的网站应用程序路径（如\LM\W3SVC\2）应该在所有的服务器上保持一致（大小写敏感）。详见KB325056 