写过稍微大型一点 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,好好去利用吧!或许老是困扰的效能问题能因此改善不少!
11
22
33