■第二方案
关于上一方案，你可能也想到，我们自订的编号使用了 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，好好去利用吧！或许老是困扰的效能问题能因此改善不少！
