优点
如果要在诸多Web页间传递一个变量,那么用 Session变量要比通过QueryString传递变量可使问题简化。
要使WEb站点具有用户化,可以考虑使用Session变量。你的站点的每位访问者都有用户化的经验,基于此,随着LDAP和诸如MS Site Server等的使用,已不必再将所有用户化过程置入Session变量了,而这个用户化是取决于用户喜好的。
你可以在任何想要使用的时候直接使用session变量,而不必事先声明它,这种方式接近于在VB中变量的使用。使用完毕后,也不必考虑将其释放,因为它将自动释放。
缺点
Session变量和cookies是同一类型的。如果某用户将浏览器设置为不兼容任何cookie,那么该用户就无法使用这个Session变量!
当一个用户访问某页面时,每个Session变量的运行环境便自动生成,这些Session变量可在用户离开该页面后仍保留20分钟!(事实上,这些变量一直可保留至“timeout”。“timeout”的时间长短由Web服务器管理员设定。一些站点上的变量仅维持了3分钟,一些则为10分钟,还有一些则保留至默认值20分钟。)所以,如果在Session中置入了较大的对象(如ADO recordsets,connections, 等等),那就有麻烦了!随着站点访问量的增大,服务器将会因此而无法正常运行!
因为创建Session变量有很大的随意性,可随时调用,不需要开发者做精确地处理,所以,过度使用session变量将会导致代码不可读而且不好维护。
虽然“你可以在任何想要使用的时候直接使用session变量,而不必事先声明它,这种方式接近于在VB中变量的使用。使用完毕后,也不必考虑将其释放,因为它将自动释放”。但是,“谁”想到那儿呢?变量的含义是什么?这些都变得不很清晰。
*********************************************************************************************************************************************************************
Session使用的优化
ASP.NET 里面 SessionState有三种可以选择的模式
有很多页面里面只需要从Session里面读取数据的而不需要写入数据到Session, 对于这些页面我们可以将页面标记为<%@ Page EnableSessi . . .%>。这样可以将页面执行时对SQL Server 数据库操作由两次减少为一次。
对于不需要使用Session的页面,我们可以将页面标记为<%@ Page EnableSessi . . .%>。
如果要在诸多Web页间传递一个变量,那么用 Session变量要比通过QueryString传递变量可使问题简化。
要使WEb站点具有用户化,可以考虑使用Session变量。你的站点的每位访问者都有用户化的经验,基于此,随着LDAP和诸如MS Site Server等的使用,已不必再将所有用户化过程置入Session变量了,而这个用户化是取决于用户喜好的。
你可以在任何想要使用的时候直接使用session变量,而不必事先声明它,这种方式接近于在VB中变量的使用。使用完毕后,也不必考虑将其释放,因为它将自动释放。
缺点
Session变量和cookies是同一类型的。如果某用户将浏览器设置为不兼容任何cookie,那么该用户就无法使用这个Session变量!
当一个用户访问某页面时,每个Session变量的运行环境便自动生成,这些Session变量可在用户离开该页面后仍保留20分钟!(事实上,这些变量一直可保留至“timeout”。“timeout”的时间长短由Web服务器管理员设定。一些站点上的变量仅维持了3分钟,一些则为10分钟,还有一些则保留至默认值20分钟。)所以,如果在Session中置入了较大的对象(如ADO recordsets,connections, 等等),那就有麻烦了!随着站点访问量的增大,服务器将会因此而无法正常运行!
因为创建Session变量有很大的随意性,可随时调用,不需要开发者做精确地处理,所以,过度使用session变量将会导致代码不可读而且不好维护。
虽然“你可以在任何想要使用的时候直接使用session变量,而不必事先声明它,这种方式接近于在VB中变量的使用。使用完毕后,也不必考虑将其释放,因为它将自动释放”。但是,“谁”想到那儿呢?变量的含义是什么?这些都变得不很清晰。
*********************************************************************************************************************************************************************
Session使用的优化
ASP.NET 里面 SessionState有三种可以选择的模式
方式 |
说明 |
优点 |
缺点 |
InProc |
会话值在aspnet_wp.exe 或 w3wp.exe的内存中保持为活动对象。这是默认选项。 |
性能最好 |
当W3WP 进程 死掉 或者进程回收后,Session信息将会丢失。 占用Web 服务器的内存用于保存Session信息 |
StateServer |
会话值被序列化并存储在单独进程 (aspnet_state.exe) 的内存中。该进程还可以在其他计算机上运行。 |
在负载均衡条件下,可以为多个Web 服务器维护Session信息 当W3WP 进程 死掉 或者进程回收后,Session信息不会丢失 |
性能比InProc方式差 |
SQL Server |
会话值被序列化并存储在 SQL Server 表中。SQL Server 的实例可以在本地运行,也可以远程运行 |
在负载均衡条件下,为多个Web 服务器维护Session信息 当W3WP 进程 死掉 或者进程回收后,Session信息不会丢失 当Web服务器死机或者重新启动后,Session信息不会丢失. |
性能比InProc方式差 缺省情况下 每个页面需要操作两次SQL Server 数据库操作。第一次读取Session,第二次写入Session. |
- 页面的EnableSessionState开关
有很多页面里面只需要从Session里面读取数据的而不需要写入数据到Session, 对于这些页面我们可以将页面标记为<%@ Page EnableSessi . . .%>。这样可以将页面执行时对SQL Server 数据库操作由两次减少为一次。
对于不需要使用Session的页面,我们可以将页面标记为<%@ Page EnableSessi . . .%>。
- 减少Session 里面存放的数据量