推薦：ASP實現不存在的網頁就自動發送郵件我們在製作網站的時候，通常會有當訪客的一些錯誤操作或我們網站本身的缺陷，造成某個不存在的頁面被訪問，這時會出現404錯誤提示信息，如果是熱心的訪客可能會給你發一封郵件提示你，當時大部
寫過稍微大型一點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，好好去利用吧！或許老是困擾的效能問題能因此改善不少！
分享：用ASP編寫更人性化的彈出窗口程序ASP實例：用ASP編寫更人性化的彈出窗口程序，來幫我們製作一個不煩人的調查的方法。用彈出窗口來顯示調查表，被認為是達到我們收集訪問用戶信息的最方便快捷的方法。當製作出第一份調查表後