web應(yīng)用程序設(shè)計論文-資料下載頁
2025-06-19 15:05本頁面
【正文】 用程序體系結(jié)構(gòu)的討論可以看出，WEB 請求會通過多個階段，每個階段花費一定的執(zhí)行時間。請求排隊通過每個步驟，完成一個步驟之后，再排隊進入下一個步驟。每個步驟很像人們在商店里排隊結(jié)帳的情況。可以把 WEB 應(yīng)用程序建模為一系列步驟（稱為 “隊列”）。應(yīng)用程序的每個組件都是一個隊列。建模為一系列隊列的典型 WEBSphere 應(yīng)用程序如圖 3 所示： 圖 3. 建模為排隊網(wǎng)絡(luò)的 WEBSphere174。 應(yīng)用程序 圖3顯示請求等待 WEB 服務(wù)器處理它們，然后等待 WEB 容器，依此類推。如果進入某個隊列的請求速率超過了此隊列處理請求的速率，請求就會聚集起來。當(dāng)出現(xiàn)請求聚集時，服務(wù)時間是不可預(yù)測的，用戶會察覺到瀏覽器會話延遲。圖3 中的隊列代表最糟糕的情況，因為 WEB 服務(wù)器可以自己處理一些請求，即不需要訪問數(shù)據(jù)庫。隊列在 UNIX174。 環(huán)境中很常見。當(dāng)應(yīng)用程序發(fā)出磁盤請求的速率快于磁盤返回數(shù)據(jù)的速率時，操作系統(tǒng)會讓磁盤請求排隊，還可能調(diào)整請求的次序以降低尋道時間。另一個隊列是運行隊列，其中包含等待運行的進程的有序列表。應(yīng)用程序會等待輪到它們使用某些有限的資源（比如 CPU）。因此，隊列調(diào)優(yōu)是一種平衡的藝術(shù)。隊列太小，就會在仍然有富余容量的情況下拒絕用戶。隊列太大，就會試圖為過多的用戶提供服務(wù)，導(dǎo)致性能很差。導(dǎo)致情況更復(fù)雜的另一個因素是，這些排隊位置并不是無成本的。保留排隊位置會導(dǎo)致內(nèi)存開銷，對于應(yīng)用服務(wù)器，這會與正在處理請求的線程爭用內(nèi)存。因此，在一般情況下，在應(yīng)用服務(wù)器上排隊并不是好方法。推薦的方法是在應(yīng)用服務(wù)器之前（比如在 WEB 服務(wù)器上）排隊。這意味著 WEB 服務(wù)器要保持與 WEB 客戶機的連接，并在應(yīng)用服務(wù)器空閑時發(fā)出請求。應(yīng)用服務(wù)器只需處理它能夠及時派發(fā)的請求。 針對開發(fā)人員的提示作為開發(fā)人員，應(yīng)該按照一些一般原則提高應(yīng)用程序的可伸縮性。這些原則可以應(yīng)用于大多數(shù) WEB 應(yīng)用程序。 應(yīng)用程序應(yīng)該以某種方式向收集系統(tǒng)提供度量值（即使收集系統(tǒng)僅僅是日志文件）。這些度量值包括訪問應(yīng)用程序中某個函數(shù)的頻率或處理一個請求花費的時間等。這并不會使應(yīng)用程序運行得更快，但是有助于了解應(yīng)用程序為什么會變慢以及代碼的哪些部分花費的時間最長。了解什么時候調(diào)用某些函數(shù)，這有助于把在系統(tǒng)上觀察到的現(xiàn)象（比如 CPU 忙或磁盤活動量高）與應(yīng)用程序中的活動（比如上傳圖像）聯(lián)系起來。能夠了解站點上發(fā)生的情況，這是擴展站點容量的關(guān)鍵。您認為不夠優(yōu)化的代碼部分可能不會造成問題。只有通過適當(dāng)?shù)亩攘?，才能發(fā)現(xiàn)真正的瓶頸。WEB 在本質(zhì)上是無狀態(tài)的。用戶發(fā)出的每個請求都獨立于以前的請求。但是，應(yīng)用程序常常是有狀態(tài)的。用戶必須登錄應(yīng)用程序以證明自己的身份，在訪問站點期間可能要維護購物車的狀態(tài)，還可能要填寫供以后使用的個人信息。跟蹤會話是一種成本很高的操作，尤其是在涉及多個服務(wù)器的情況下。在單一服務(wù)器上運行的 WEB 應(yīng)用程序可以把會話信息放在內(nèi)存中，在服務(wù)器上運行的任何 WEB 應(yīng)用程序?qū)嵗伎梢栽L問共享內(nèi)存。常常會給用戶分配一個標(biāo)志，這個標(biāo)志標(biāo)識內(nèi)存中的會話。考慮一下在涉及第二個應(yīng)用服務(wù)器時會發(fā)生什么。如果用戶的第一個請求發(fā)送給一個服務(wù)器，第二個請求發(fā)送給另一個服務(wù)器，那么會存在兩個單獨的會話，它們并不相同。此問題的常用解決方案是，把會話存儲在數(shù)據(jù)庫而不是內(nèi)存中。這種方法導(dǎo)致的問題是，對于每個請求，需要增加數(shù)據(jù)庫讀操作，還可能涉及數(shù)據(jù)庫寫操作。每個 WEB 應(yīng)用服務(wù)器都需要這個數(shù)據(jù)庫。一個解決方案是，只在需要會話的地方使用會話。應(yīng)用程序并不為每個請求裝載會話，而是只在需要會話時裝載會話。這會減少對后端數(shù)據(jù)庫的請求數(shù)量。另一個方法是加密會話數(shù)據(jù)并把它發(fā)送回客戶機，這樣就不需要在本地存儲會話。在用戶的 cookie 中能夠存儲的數(shù)據(jù)量是有限的，但是 RFC 2109 規(guī)定客戶機應(yīng)該能夠為每個域名存儲至少 20 個 cookie，每個 cookie 至少可以保存 4K 字節(jié)的數(shù)據(jù)。與其他部分相比，應(yīng)用程序的某些部分會更頻繁地修改數(shù)據(jù)。新聞網(wǎng)站可能每個月只修改頂級分類列表一次。因此，對于每個請求都通過查詢數(shù)據(jù)庫獲取最新的分類列表是很浪費的。同樣，包含新聞稿的頁面在其整個生命周期中可能只修改一兩次，所以不需要為每個請求重新生成它。緩存意味著把處理成本很高的請求的結(jié)果存儲起來，供以后使用。可以緩存分類列表或整個頁面。在尋找應(yīng)該緩存的數(shù)據(jù)時，還應(yīng)該考慮是否確實需要直接提供這些信息。需要在每個頁面上顯示用戶的購物車嗎？只顯示總金額怎么樣？或者只顯示一個簡單的鏈接 “view the contents of your cart”。EdgeSide Includes (ESI) 是一種標(biāo)記語言，可以用它把網(wǎng)頁劃分為單獨的可緩存的實體。應(yīng)用程序負責(zé)生成包含 ESI 標(biāo)記的 HTML 文檔，還負責(zé)生成組件。WEB 應(yīng)用程序前面的代理緩存根據(jù)各個部分重新組裝最終的文檔，負責(zé)緩存一些組件并為其他組件發(fā)出請求。清單 1 給出一個 ESI 文檔示例。結(jié)束語結(jié)束語筆者結(jié)合A 企業(yè)的實際需求, 對WEB 應(yīng)用系統(tǒng)的主要技術(shù)支持層面進行了探討, 提出了基于WEB 的三層網(wǎng)絡(luò)計算模式為基礎(chǔ)的WEB 應(yīng)用系統(tǒng)技術(shù)支持平臺, 該方案的實施為企業(yè)實現(xiàn)前后臺數(shù)據(jù)交換、整合內(nèi)外部資源、協(xié)調(diào)和改進業(yè)務(wù)流程、實現(xiàn)其WEB 理念, 提供了有效的技術(shù)支持。A 企業(yè)原先存在的信息交互和共享困難、對客戶的請求反應(yīng)遲鈍、WEB 決策支持不力等現(xiàn)象得到了明顯的改善。在國家壓縮投資規(guī)模的宏觀調(diào)控背景下, 2004 年上半年該企業(yè)產(chǎn)品銷售收入與凈利潤均同比增長了30% 以上, 其WEB 應(yīng)用系統(tǒng)發(fā)揮了重要作用。致謝 參考文獻參考文獻 [1] [J].。 [2] 汪云,[J].襄樊學(xué)院報,2006,27(2)。[3] 張念魯, 程序設(shè)計教程[M].高等教育出版社,。[4] 宣小平,但正剛,[M].人民郵電出版社,。[5] 丁貴廣,閆允一,[M].機械工業(yè)出版社,。[6] 薛元昀,顧佳霙,[M].清華大學(xué)出版
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1