寫過稍微大型一點 ASP 的人都知道，Session 這個對象真是好用，它可以用來記錄使用者私有的資料變量，既安全又方便。但是你真的知道 Session 的運作原理嗎？或許了解以后，你就再也不太敢使用這個令人又愛又恨的對象。雖然轉(zhuǎn)而替代之的方法稍嫌麻煩，但在長期考量之下，也就不得不這么做了

首先來講講 Session 的好處，它可以用來記錄客戶端私有的資料變量，并且在時間范圍內(nèi)不會消失。這真的是很重要的功能，尤其是有會員的系統(tǒng)必須要用到的。像是會員的登入帳號、時間、狀態(tài)以及許許多多該記錄的實時數(shù)據(jù)﹝如購物系統(tǒng)記錄使用者的購物籃內(nèi)的商品﹞，這些信息屬于各使用者私人所需要，通常開發(fā)者都是使用 Session 記錄處理。 

　　然而，在 ASP 中的 Session 是使用 Cookies 所構(gòu)成，服務(wù)器將所有的 Session 內(nèi)記錄的資料，以 Cookies 的方式傳至用戶的瀏覽器。通常一般瀏覽器會將這些 Cookies 存起來，每當(dāng)使用者點選連結(jié)，再次與服務(wù)器做聯(lián)機(jī)時，瀏覽器就會把這些 Cookies 傳回 Server 供做處理。這即是 Session 的運作原理，當(dāng)資料量大一點時，由于必須傳出去又收回來，不但吃線路頻寬，效能相對降低，因為 Server 必須花費更多的資源在做聯(lián)機(jī)處理和重新配置內(nèi)存等初始動作。現(xiàn)在你可能會想『我必須用這功能，只好犧牲點了』，不過本文講 Session 一方面是教導(dǎo)大家少用；另一方面當(dāng)然是有替代辦法，緊接著上場的，就是同屬 Global.asa 內(nèi)的 Application 對象。 

　　Application 也是記錄處理暫時資料的好手，各方面的能力和用法都和 Session 一樣，只不過相較之下，它所記錄的資料是屬于公用的，也就是任何使用者都可以共享的變量空間。Application 不像 Session ，不是將資料傳給使用者，等下一次聯(lián)機(jī)再讀取回來，它是直接記錄在 Server 上的內(nèi)存，相對之下效能上快上 Session 許多。 

　　由于 Application 對象是公用的，首先必須做的，就是要把一塊公用的區(qū)域規(guī)劃給各個使用者，讓每個用戶擁有自己的區(qū)域可以記錄資料，以達(dá)到仿真 Session 的目的?，F(xiàn)在有兩種做法： 

　　一、在 Server 激活時事先初始化建立及分配使用者內(nèi)存空間，通常這種做法雖然一 Server 開機(jī)就先占了許多資源，但也省去了以后每當(dāng)使用者聯(lián)機(jī)就必須做一次分配的麻煩。但有個限制，使用這種方法必須限制最大人數(shù)，由于是一激活就初始化，我們只能預(yù)估建立某數(shù)量的內(nèi)存空間，所以這種方法通常用于聊天室這種小型的程序上。 

　　二、這種方法對于大型應(yīng)用程序來說應(yīng)該算較恰當(dāng)?shù)?，采用動態(tài)的分配法，當(dāng)使用者第一次聯(lián)機(jī)到 Server 上才開始分配資源給此用戶。這兩種仿真 Session 的方案，目的都是減輕 Session 資源的消耗，但畢竟還是無法完全替代，我們還是需要使用到一點點 Session，至少對 Server 已經(jīng)能減輕不少負(fù)擔(dān)了。 

　　第一方案 

　　首先我們開始第一個方案的實作，由于是激活時初始化 Application，我們當(dāng)然要從 Global.asa中著手： 

　　已經(jīng)完成初始化了，但如何使用呢？我們只要在使用者登入的地方，把原本使用 Session 儲存的資料，如帳號、登入時間，改成我們建立好的 Application 對象中就可以了： 


　　要取得使用者的相關(guān)變量數(shù)據(jù)則就像下面的做法： 

Response.Write(Application("User_Account_" & Session("Index")) 

　　你可能會發(fā)現(xiàn)，不是說不要使用 Session 嗎？那為什么上面的原始碼中還有 Session 的存在？前面也說過，這替代方案并不能完全代替掉 Session，瀏覽器并不是一直和 Server 處于聯(lián)機(jī)狀態(tài)的，讀取完頁面就斷線，那我們要怎么知道下次聯(lián)機(jī)的還是同一個人呢？這時候就必須要靠 Session，我們給使用者一組實時的編號，此編號就是使用者于 Application 上變量空間的號碼，你可以想象成銀行中有很多的保險箱，你擁有一支鑰匙，而鑰匙上有編號，鑰匙上的編號可以讓行員帶領(lǐng)你去你自己的保險箱。此方法尚還有改進(jìn)之處，但對小型的應(yīng)用程序已經(jīng)是很夠用了。 

　　第二方案 

　　關(guān)于上一方案，你可能也想到，我們自訂的編號使用了 Session 來記錄，講到編號，Session 對象有提供一個『 SessionID 』方法。沒錯，不管我們要不要使用，Server 都會自動幫每個用戶編列號碼，且此號碼不會重復(fù)，至于這號碼就是用 Session.SessionID 取得。這編列號碼是 Session 一定會做的動作，我們就可利用它代替我們自己寫的編號程序，亦又省了一道功夫，甚至有更大的擴(kuò)充性。但基本上，上面的第一個方案還是有它的用途在，像是會限制人數(shù)的聊天室等等小應(yīng)用程序，接下來的第二替代方案，就是針對較大型的系統(tǒng)了。 

　　每秒上站人數(shù)達(dá)數(shù)百數(shù)千甚至上萬人的網(wǎng)站，使用之前的方案，必定是行不通的。假設(shè)你將上限人數(shù)設(shè) 10000 ，Server 一激活就會幫你切出一萬個區(qū)域準(zhǔn)備給一萬個使用者，假若一個區(qū)域中有 5 個變量，一個變量占 32 字節(jié)(Byte)，10000 個就占了 320000 K(320MB) 以上，Server 一激活就塞了那么多的垃圾到內(nèi)存，效能勢必還沒上戰(zhàn)場就降低不少；而且別看這些數(shù)字很少，以為自己的 512 MB 會夠用，上面的數(shù)字是假設(shè)一個最低數(shù)字，加上 Server 在配置內(nèi)存時會額外使用到多少資源不得而知，所以只會更多不會更低。因此解決辦法只有動態(tài)配置使用者變量空間，當(dāng)有使用者與 Server 聯(lián)機(jī)時才切一塊區(qū)域出來，如此便不須要事先就配置好龐大內(nèi)存。 

　　第二方案做起來是比較簡單，請把第一方案的東西全部丟掉，我們不需要動到 Global.asa，只需要改使用者登入的地方和其它有用到的地方： 

　　要取得使用者的相關(guān)變量數(shù)據(jù)則就像下面的做法： 

　　以往看很多書，都寫著 Session 吃資源吃的很兇，盡量不要用，可是必須用的時候還是得用，書里又都沒教較妥當(dāng)?shù)慕鉀Q辦法?，F(xiàn)在當(dāng)你懂了如何替代 Session，好好去利用吧！或許老是困擾的效能問題能因此改善不少！