技巧 19: 利用瀏覽器的驗證功能現(xiàn)今的瀏覽器對一些高級功能如 XML、DHTML、Java 小程序和遠程數(shù)據(jù)服務提供支持。盡可能使用這些功能。所有這些技術(shù)都可以執(zhí)行客戶機端驗證和數(shù)據(jù)緩存,免去了到 Web 服務器的往返。如果您在運行一個智能瀏覽器,那么瀏覽器就能為您進行一些驗證(例如,在執(zhí)行 POST 之前,檢查信用卡校驗和是否有效)。盡可能使用這一功能。通過減少客戶-服務器之間的往返,可降低 Web 服務器上的負載,并能減少網(wǎng)絡通信量(雖然發(fā)送到瀏覽器的第一個頁面可能比較大)以及服務器訪問的任何后端資源。此外,用戶不必像住常一樣讀取新頁,從而用戶的感覺會好一些。這樣做并不意味著您可以不進行服務器端驗證 - 您還應始終進行服務器端驗證。這可以防止由于某種原因(如黑客,或瀏覽器不運行客戶機端驗證例程)客戶機產(chǎn)生錯誤的數(shù)據(jù)。 人們已經(jīng)進行了大量的工作,開發(fā)“獨立于瀏覽器”的 HTML。正是由于這種憂慮,開發(fā)人員不愿再使用流行的瀏覽器功能,但這些功能本可以改善性能。對于一些真正的高性能站點,必須關(guān)心瀏覽器“訪問”問題,一個好的策略是優(yōu)化頁面,使其適應流行的瀏覽器。使用瀏覽器功能組件,可以在 ASP 中方便地檢測到瀏覽器功能。Microsoft FrontPage 等工具有助于設計適合于瀏覽器和指定 HTML 版本的代碼。參見 When is Better Worse?Weighing the Technology Trade-Offs,以了解更進一步的討論。 技巧 20:避免在循環(huán)語句中使用字符串串聯(lián)許多人在循環(huán)語句中建立一個字符串,如下所示: s = ?<table>? & vbCrLf For Each fld in rs.Fields s = s & ? <th>? & fld.Name & ?</th> ? Next While Not rs.EOF s = s & vbCrLf & ? <tr>? For Each fld in rs.Fields s = s & ? <td>? & fld.Value & ?</td> ? Next s = s & ? </tr>? rs.MoveNext Wend s = s & vbCrLf & ?? & vbCrLf Response.Write s 采用這種方法會出現(xiàn)一些問題。第一個問題是反復串聯(lián)字符串需要花兩次方的時間,更通俗地說,運行這種循環(huán)語句所花的時間與記錄數(shù)乘以字段數(shù)所得值的平方成正比。舉一個更簡單的例子,就可以更清楚地說明這一問題。 s = ?? For i = Asc(?A?) to Asc(?Z?) s = s & Chr(i) Next 在第一次迭代中,您獲得了一個字符的字符串 ?A?。在第二次迭代中,VBScript 必須重新分配字符串并將兩個字符 (?AB?) 復制到 s 中。在第三次迭代中,它還必須再次重新分配 s 并將三個字符復制到 s 中。在 N 次(第 26 次)迭代中,它必須重新分配并將 N 個字符復制到 s 中?偣簿褪 1+2+3+...+N,即 N*(N+1)/2 次復制。 在上面的記錄集舉例中,如果有 100 個記錄和 5 個字段,內(nèi)循環(huán)將執(zhí)行 100*5 = 500 次,所有的復制和重新分配所花的時間與 500*500 = 250,000 成正比。這對于中等大小的記錄集來說復制操作太多了。 在本例中,代碼可以用 Response.Write() 或內(nèi)嵌腳本 (<% = fld.Value %>) 替代字符串串聯(lián)來改進。如果啟用了響應緩沖的話(應該的),這樣做就會更快,因為 Response.Write 只將數(shù)據(jù)附加到響應緩沖的末尾。并不涉及重新分配,因此效率很高。 在將 ADO 記錄集轉(zhuǎn)換為 HTML 表的特定情況下,應考慮使用 GetRows 或 GetString。 如果在 JScript 中串聯(lián)字符串,特別建議使用 += 運算符,即,使用 s += ?某字符串?,而不使用 s = s + ?某字符串?。 技巧 21:啟用瀏覽器和代理緩存在默認情況下,ASP 禁止在瀏覽器和代理中進行緩存。這是有意義的,因為就實質(zhì)而言 ASP 頁面是動態(tài)的,上面有隨時間不斷變化的潛在信息。如果頁面不要求在每個視圖上進行刷新,您應啟用瀏覽器和代理緩存。這可使瀏覽器和代理在一定的時間內(nèi)使用頁面的“緩存”副本,您可以控制時間的長短。緩存可以大大減輕服務器上的負載,縮短用戶的等待時間。 哪一種動態(tài)頁面可作為要緩存的頁面呢?下面舉一些例子:
注意,在使用瀏覽器或代理緩存的情況下,Web 服務器上記錄的訪問次數(shù)減少了。如果您想準確地測量所有頁面視圖或張?zhí),您就不希望使用瀏覽器和代理緩存。 瀏覽器緩存由 HTTP“過期”報頭控制,該報頭由 Web 服務器發(fā)送給瀏覽器。ASP 提供兩個簡單的機制發(fā)送此報頭。要設置頁面使其過多少分鐘后到期,則應設置 Response.Expires 屬性。下面的例子告訴瀏覽器內(nèi)容在 10 分鐘內(nèi)過期: <% Response.Expires = 10 %> 若將 Response.Expires 設置為負數(shù)或 0,則禁用緩存。一定要使用大的負數(shù),如 -1000(略多于一天),以避免服務器和瀏覽器時鐘之間的不匹配。第二個屬性 Response.ExpiresAbsolute 將使您設置內(nèi)容過期的具體時間: <% Response.ExpiresAbsolute = #May 31,2001 13:30:15# %> 您可以不使用 Response 對象設置過期時間,而將 <META> 標記寫進 HTML,通常寫在 HTML 文件的 <HEAD> 部分。一些瀏覽器將遵照此指令,而代理則不然。 <META HTTP-EQUIV=?Expires? VALUE=?May 31,2001 13:30:15?> 最后,您可以使用 Response.CacheControl 屬性,指示其內(nèi)容是否可以讓 HTTP 代理緩存。若將此屬性設置為“Public”,代理就可以緩存此內(nèi)容。 <% Response.CacheControl = ?Public? %> 在默認情況下,此屬性被設置為“Private”。注意,對于顯示某用戶特定數(shù)據(jù)的頁面,不應啟用代理緩存,因為代理可能給用戶提供屬于其他用戶的頁面。 技巧 22:盡可能使用 Server.Transfer 代替 Response.RedirectResponse.Redirect 讓瀏覽器請求另一個頁面。此函數(shù)常用來將用戶重定向到一個登錄或錯誤頁面。因為重定向強制請求新頁面,結(jié)果是瀏覽器必須到 Web 服務器往返兩次,且 Web 服務器必須多處理一個請求。IIS 5.0 引入了一個新的函數(shù) Server.Transfer,它將執(zhí)行轉(zhuǎn)移到同一臺服務器上的另一個 ASP 頁。這樣就避免多余的瀏覽器-Web-服務器的往返,從而改善了總體系統(tǒng)性能以及縮短了用戶的響應時間。檢查“重定向”中的“新的方向”,上面應該是 Server.Transfer 和 Server.Execute。 另請參見 Leveraging ASP in IIS 5.0,了解 IIS 5.0 和 ASP 3.0 新功能的完整列表。 技巧 23:在目錄 URL 中使用后斜杠一個相關(guān)的技巧是確保在指向目錄的 URL 中使用后斜杠 (/)。如果您省略了后斜杠,瀏覽器就會向服務器發(fā)出請求,只是為了告訴服務器,它在請求目錄。瀏覽器就會發(fā)出第二個請求,將斜杠附加到 URL 后面,只有此后,服務器才能以該目錄的默認文檔或目錄列表(如果沒有默認文檔且啟用了目錄瀏覽的話)響應。附加斜杠可省去第一個、無用的住返。為便于用戶閱讀,可以省略顯示名稱中的后斜杠。 例如,寫: <a href=?http://msdn.microsoft.com/workshop/? title=?MSDN Web Workshop?>http://msdn.microsoft.com/workshop</a> 這也適用于指向 Web 站點上主頁的 URL:使用下面的:<a href=?http://msdn.microsoft.com/?>,而不使用 <a href=?http://msdn.microsoft.com?>。 技巧 24:避免使用服務器變量訪問服務器變量會使 Web 站點向服務器發(fā)出一個特殊請求,并收集所有服務器變量,而不只是您請求的那個變量。這種情況類似于,在發(fā)霉的閣樓上,在一個文件夾中查找某個文件。當您想要找那個文件時,您必須去閣樓上,先找到文件夾,然后才能找到這份文件。當您請求服務器變量時,發(fā)生的情況是一樣的 - 您第一次請求服務器變量時,就會使性能受到影響。后面的對其它服務器變量的請求,則不會對性能產(chǎn)生影響。 決不要訪問非限定的 Request 對象(例如,Request("Data"))。對于不在 Request.Cookies、Request.Form、Request.QueryString 或 Request.ClientCertificate 中的項目,則隱式調(diào)用 Request.ServerVariables。Request.ServerVariables 集合比其它集合慢得多。 技巧 25:升級到最新和最出色的系統(tǒng)組件是恒定的,我們建議您將它們升級到最新和最好的配置。最好升級到 Windows 2000(因此,也應升級到 IIS 5.0、ADO 2.5、MSXML 2.5、Internet Explorer 5.0、VBScript 5.1 和 JScript 5.1)。在多處理器計算機上,實施 IIS 5.0 和 ADO 2.5 可顯著改善性能。在 Windows 2000 下,ASP 可以很好地擴展到四個處理器或更多,而在 IIS 4.0 下,ASP 的擴展性不能超出兩個處理器。在應用程序中使用的腳本代碼和 ADO 越多,升級到 Windows 2000 之后,性能的改善就會越多。 如果目前還不能升級到 Windows 2000,您可以升級到 SQL Server、ADO、VBScript 和 JScript、MSXML、Internet Explorer 和 NT 4 Service Packs 的最新版本。它們均可提高性能和可靠性。 技巧 26:優(yōu)化 Web 服務器有多種 IIS 優(yōu)化參數(shù)可以改善站點性能。例如,對于 IIS 4.0,我們常常發(fā)現(xiàn),增加 ASP ProcessorThreadMax 參數(shù)(參見 IIS 文檔)可以顯著改善性能,特別是在傾向于等待后端資源(如數(shù)據(jù)庫)或其它中間產(chǎn)品(如屏幕刷)的站點上。在 IIS 5.0 中,您可能發(fā)現(xiàn)啟用 ASP Thread Gating 比查找一個 AspProcessorThreadMax 最佳設置效率更高,這一點現(xiàn)在已為大家所熟知。 有關(guān)較好的參考資料,參見下面的優(yōu)化 IIS。 最佳的配置設置取決于(其中一些因素)應用程序代碼、運行所在的系統(tǒng)硬件和客戶機工作負荷。找到最佳設置的唯一方法是進行性能測試,這是我們在下一個技巧中所要討論的。 技巧 27:進行性能測試正如我們在前面已經(jīng)講過,性能是一個特征。如果您想要改善站點的性能,那么就制定一個性能目標,然后逐步改進,直到達到目標為止。不要,就不進行任何性能測試。通常,在項目結(jié)束時,再作必需的結(jié)構(gòu)調(diào)整已經(jīng)為時太晚,您的客戶將為此感到失望。將性能測試作為您日常測試的一部分來進行?梢詫蝹組件分別進行性能測試,如針對 ASP 頁或 COM 對象,或?qū)⒄军c作為一個整體來測試。 許多人使用單個瀏覽器請求頁面,來測試 Web 站點的性能。這樣做就會給您一個感覺,即站點的響應能力很好,但這樣做實際上并不能告訴您在負載條件下站點的性能如何。 一般情況下,要想準確地測試性能,您需要一個專門的測試環(huán)境。此環(huán)境應包括硬件,其處理器速度、處理器數(shù)量、內(nèi)存、磁盤、網(wǎng)絡配置等方面與生產(chǎn)環(huán)境的硬件相似。其次,您必須指定客戶機的工作負荷:有多少同時的用戶,他們發(fā)出請求的頻率,他們點擊頁面的類型等等。如果您沒有站點實際使用情況的數(shù)據(jù),您必須估計一下使用的情況。最后,您需要一個可以模擬預期客戶機工作負荷的工具。有了這些工具,您就可以開始回答諸如“如果我有 N 個同時的用戶,那么需要多少服務器?”之類的問題。您還可以找出出現(xiàn)瓶頸的原因,并以此為目標進行優(yōu)化。 下面列出了一些好的 Web 負載測試工具。我們特別推薦 Microsoft Web Application Stress (WAS) 工具包。WAS 可使您記錄測試腳本,然后模擬數(shù)百或成千上萬個用戶訪問 Web 服務器。WAS 報告很多統(tǒng)計信息,包括每秒鐘的請求數(shù),響應時間分布情況和錯誤計數(shù)。WAS 有豐富的客戶機界面和基于 Web 的界面兩種,Web 界面可使您進行遠程測試。 一定要閱讀 IIS 5.0 Tuning Guide。 技巧 28:閱讀資源鏈接下面是一些與性能有關(guān)的出色的資源鏈接。如果您想了解有關(guān)信息,請閱讀 Developing Scalable Web Applications。 資源
|
溫馨提示:喜歡本站的話,請收藏一下本站!