ASP中Session技巧 默认过期时间为20分钟
程序员文章站
2022-04-14 19:02:01
写过稍微大型一点 asp 的人都知道，session 这个对象真是好用，它可以用来记录使用者私有的资料变量，既安全又方便。但是你真的知道 session 的运作原理吗？或许...
写过稍微大型一点 asp 的人都知道，session 这个对象真是好用，它可以用来记录使用者私有的资料变量，既安全又方便。但是你真的知道 session 的运作原理吗？或许了解以后，你就再也不太敢使用这个令人又爱又恨的对象。虽然转而替代之的方法稍嫌麻烦，但在长期考量之下，也就不得不这么做了
首先来讲讲 session 的好处，它可以用来记录客户端私有的资料变量，并且在时间范围内不会消失。这真的是很重要的功能，尤其是有会员的系统必须要用到的。像是会员的登入帐号、时间、状态以及许许多多该记录的实时数据﹝如购物系统记录使用者的购物篮内的商品﹞，这些信息属于各使用者私人所需要，通常开发者都是使用 session 记录处理。
然而，在 asp 中的 session 是使用 cookies 所构成，服务器将所有的 session 内记录的资料，以 cookies 的方式传至用户的浏览器。通常一般浏览器会将这些 cookies 存起来，每当使用者点选连结，再次与服务器做联机时，浏览器就会把这些 cookies 传回 server 供做处理。这即是 session 的运作原理，当资料量大一点时，由于必须传出去又收回来，不但吃线路频宽，效能相对降低，因为 server 必须花费更多的资源在做联机处理和重新配置内存等初始动作。现在你可能会想『我必须用这功能，只好牺牲点了』，不过本文讲 session 一方面是教导大家少用；另一方面当然是有替代办法，紧接着上场的，就是同属 global.asa 内的 application 对象。
application 也是记录处理暂时资料的好手，各方面的能力和用法都和 session 一样，只不过相较之下，它所记录的资料是属于公用的，也就是任何使用者都可以共享的变量空间。application 不像 session ，不是将资料传给使用者，等下一次联机再读取回来，它是直接记录在 server 上的内存，相对之下效能上快上 session 许多。
由于 application 对象是公用的，首先必须做的，就是要把一块公用的区域规划给各个使用者，让每个用户拥有自己的区域可以记录资料，以达到仿真 session 的目的。现在有两种做法：
一、在 server 激活时事先初始化建立及分配使用者内存空间，通常这种做法虽然一 server 开机就先占了许多资源，但也省去了以后每当使用者联机就必须做一次分配的麻烦。但有个限制，使用这种方法必须限制最大人数，由于是一激活就初始化，我们只能预估建立某数量的内存空间，所以这种方法通常用于聊天室这种小型的程序上。
二、这种方法对于大型应用程序来说应该算较恰当的，采用动态的分配法，当使用者第一次联机到 server 上才开始分配资源给此用户。这两种仿真 session 的方案，目的都是减轻 session 资源的消耗，但毕竟还是无法完全替代，我们还是需要使用到一点点 session，至少对 server 已经能减轻不少负担了。
第一方案
首先我们开始第一个方案的实作，由于是激活时初始化 application，我们当然要从 global.asa中着手：
已经完成初始化了，但如何使用呢？我们只要在使用者登入的地方，把原本使用 session 储存的资料，如帐号、登入时间，改成我们建立好的 application 对象中就可以了：
'寻找未被使用的空间
for i = 1 to application("clientmax")
if application("user_status_" & i) = 0 then
'使用者暂时编号
session("index") = i
'锁定
application application.lock
'设成已使用的状态
application("user_status_" & i) = 1 '放入变量数据
application("user_account_" & i) = account
application("user_logtime_" & i) = now()
'解除锁定
application.unlock
exit for
end if
next
要取得使用者的相关变量数据则就像下面的做法：
response.write(application("user_account_" & session("index"))
你可能会发现，不是说不要使用 session 吗？那为什么上面的原始码中还有 session 的存在？前面也说过，这替代方案并不能完全代替掉 session，浏览器并不是一直和 server 处于联机状态的，读取完页面就断线，那我们要怎么知道下次联机的还是同一个人呢？这时候就必须要靠 session，我们给使用者一组实时的编号，此编号就是使用者于 application 上变量空间的号码，你可以想象成银行中有很多的保险箱，你拥有一支钥匙，而钥匙上有编号，钥匙上的编号可以让行员带领你去你自己的保险箱。此方法尚还有改进之处，但对小型的应用程序已经是很够用了。
第二方案
关于上一方案，你可能也想到，我们自订的编号使用了 session 来记录，讲到编号，session 对象有提供一个『 sessionid 』方法。没错，不管我们要不要使用，server 都会自动帮每个用户编列号码，且此号码不会重复，至于这号码就是用 session.sessionid 取得。这编列号码是 session 一定会做的动作，我们就可利用它代替我们自己写的编号程序，亦又省了一道功夫，甚至有更大的扩充性。但基本上，上面的第一个方案还是有它的用途在，像是会限制人数的聊天室等等小应用程序，接下来的第二替代方案，就是针对较大型的系统了。
每秒上站人数达数百数千甚至上万人的网站，使用之前的方案，必定是行不通的。假设你将上限人数设 10000 ，server 一激活就会帮你切出一万个区域准备给一万个使用者，假若一个区域中有 5 个变量，一个变量占 32 字节(byte)，10000 个就占了 320000 k(320mb) 以上，server 一激活就塞了那么多的垃圾到内存，效能势必还没上战场就降低不少；而且别看这些数字很少，以为自己的 512 mb 会够用，上面的数字是假设一个最低数字，加上 server 在配置内存时会额外使用到多少资源不得而知，所以只会更多不会更低。因此解决办法只有动态配置使用者变量空间，当有使用者与 server 联机时才切一块区域出来，如此便不须要事先就配置好庞大内存。
第二方案做起来是比较简单，请把第一方案的东西全部丢掉，我们不需要动到 global.asa，只需要改使用者登入的地方和其它有用到的地方：
'锁定 applicationapplication.lock '放入变量数据
application("user_account_" & session.sessionid) = account
application("user_logtime_" & session.sessionid) = now() '解除锁定application.unlock
要取得使用者的相关变量数据则就像下面的做法：
response.write(application("user_account_" & session.sessionid))
以往看很多书，都写着 session 吃资源吃的很凶，尽量不要用，可是必须用的时候还是得用，书里又都没教较妥当的解决办法。现在当你懂了如何替代 session，好好去利用吧！或许老是困扰的效能问题能因此改善不少！
首先来讲讲 session 的好处，它可以用来记录客户端私有的资料变量，并且在时间范围内不会消失。这真的是很重要的功能，尤其是有会员的系统必须要用到的。像是会员的登入帐号、时间、状态以及许许多多该记录的实时数据﹝如购物系统记录使用者的购物篮内的商品﹞，这些信息属于各使用者私人所需要，通常开发者都是使用 session 记录处理。
然而，在 asp 中的 session 是使用 cookies 所构成，服务器将所有的 session 内记录的资料，以 cookies 的方式传至用户的浏览器。通常一般浏览器会将这些 cookies 存起来，每当使用者点选连结，再次与服务器做联机时，浏览器就会把这些 cookies 传回 server 供做处理。这即是 session 的运作原理，当资料量大一点时，由于必须传出去又收回来，不但吃线路频宽，效能相对降低，因为 server 必须花费更多的资源在做联机处理和重新配置内存等初始动作。现在你可能会想『我必须用这功能，只好牺牲点了』，不过本文讲 session 一方面是教导大家少用；另一方面当然是有替代办法，紧接着上场的，就是同属 global.asa 内的 application 对象。
application 也是记录处理暂时资料的好手，各方面的能力和用法都和 session 一样，只不过相较之下，它所记录的资料是属于公用的，也就是任何使用者都可以共享的变量空间。application 不像 session ，不是将资料传给使用者，等下一次联机再读取回来，它是直接记录在 server 上的内存，相对之下效能上快上 session 许多。
由于 application 对象是公用的，首先必须做的，就是要把一块公用的区域规划给各个使用者，让每个用户拥有自己的区域可以记录资料，以达到仿真 session 的目的。现在有两种做法：
一、在 server 激活时事先初始化建立及分配使用者内存空间，通常这种做法虽然一 server 开机就先占了许多资源，但也省去了以后每当使用者联机就必须做一次分配的麻烦。但有个限制，使用这种方法必须限制最大人数，由于是一激活就初始化，我们只能预估建立某数量的内存空间，所以这种方法通常用于聊天室这种小型的程序上。
二、这种方法对于大型应用程序来说应该算较恰当的，采用动态的分配法，当使用者第一次联机到 server 上才开始分配资源给此用户。这两种仿真 session 的方案，目的都是减轻 session 资源的消耗，但毕竟还是无法完全替代，我们还是需要使用到一点点 session，至少对 server 已经能减轻不少负担了。
第一方案
首先我们开始第一个方案的实作，由于是激活时初始化 application，我们当然要从 global.asa中着手：
已经完成初始化了，但如何使用呢？我们只要在使用者登入的地方，把原本使用 session 储存的资料，如帐号、登入时间，改成我们建立好的 application 对象中就可以了：
复制代码 代码如下:
'寻找未被使用的空间
for i = 1 to application("clientmax")
if application("user_status_" & i) = 0 then
'使用者暂时编号
session("index") = i
'锁定
application application.lock
'设成已使用的状态
application("user_status_" & i) = 1 '放入变量数据
application("user_account_" & i) = account
application("user_logtime_" & i) = now()
'解除锁定
application.unlock
exit for
end if
next
要取得使用者的相关变量数据则就像下面的做法：
response.write(application("user_account_" & session("index"))
你可能会发现，不是说不要使用 session 吗？那为什么上面的原始码中还有 session 的存在？前面也说过，这替代方案并不能完全代替掉 session，浏览器并不是一直和 server 处于联机状态的，读取完页面就断线，那我们要怎么知道下次联机的还是同一个人呢？这时候就必须要靠 session，我们给使用者一组实时的编号，此编号就是使用者于 application 上变量空间的号码，你可以想象成银行中有很多的保险箱，你拥有一支钥匙，而钥匙上有编号，钥匙上的编号可以让行员带领你去你自己的保险箱。此方法尚还有改进之处，但对小型的应用程序已经是很够用了。
第二方案
关于上一方案，你可能也想到，我们自订的编号使用了 session 来记录，讲到编号，session 对象有提供一个『 sessionid 』方法。没错，不管我们要不要使用，server 都会自动帮每个用户编列号码，且此号码不会重复，至于这号码就是用 session.sessionid 取得。这编列号码是 session 一定会做的动作，我们就可利用它代替我们自己写的编号程序，亦又省了一道功夫，甚至有更大的扩充性。但基本上，上面的第一个方案还是有它的用途在，像是会限制人数的聊天室等等小应用程序，接下来的第二替代方案，就是针对较大型的系统了。
每秒上站人数达数百数千甚至上万人的网站，使用之前的方案，必定是行不通的。假设你将上限人数设 10000 ，server 一激活就会帮你切出一万个区域准备给一万个使用者，假若一个区域中有 5 个变量，一个变量占 32 字节(byte)，10000 个就占了 320000 k(320mb) 以上，server 一激活就塞了那么多的垃圾到内存，效能势必还没上战场就降低不少；而且别看这些数字很少，以为自己的 512 mb 会够用，上面的数字是假设一个最低数字，加上 server 在配置内存时会额外使用到多少资源不得而知，所以只会更多不会更低。因此解决办法只有动态配置使用者变量空间，当有使用者与 server 联机时才切一块区域出来，如此便不须要事先就配置好庞大内存。
第二方案做起来是比较简单，请把第一方案的东西全部丢掉，我们不需要动到 global.asa，只需要改使用者登入的地方和其它有用到的地方：
复制代码 代码如下:
'锁定 applicationapplication.lock '放入变量数据
application("user_account_" & session.sessionid) = account
application("user_logtime_" & session.sessionid) = now() '解除锁定application.unlock
要取得使用者的相关变量数据则就像下面的做法：
复制代码 代码如下:
response.write(application("user_account_" & session.sessionid))
以往看很多书，都写着 session 吃资源吃的很凶，尽量不要用，可是必须用的时候还是得用，书里又都没教较妥当的解决办法。现在当你懂了如何替代 session，好好去利用吧！或许老是困扰的效能问题能因此改善不少！