【文章內(nèi)容簡介】 求就會使磁盤接近飽和（ 10msec/request / 1 second = 100 requests/second）。如果要發(fā)送 10K 的文檔，就會產(chǎn)生大 約 8mbit/sec 的 WEB 通信流（ 100 requests/second * 10 KBytes/request * 8bits/byte）。如果可以從內(nèi)存緩存中獲取文件，就可以降低平均服務(wù)時間，因此增加服務(wù)器每秒能夠處理的連接數(shù)。如果您有磁盤服務(wù)時間或平均請求延時的真實數(shù)據(jù)，可以把它們放進(jìn)上面的算式，從而計算出更準(zhǔn)確的性能估計值。 既然服務(wù)器的處理容量是平均請求服務(wù)時間的倒數(shù)，那么如果服務(wù)時間加倍，服務(wù)器的處理容量（每秒處理的連接數(shù)）就會減半。請記住這一點，下面看看動態(tài)應(yīng)用程序的情況。 動態(tài)網(wǎng)頁工作原理 動態(tài)應(yīng)用程序的流程依賴于應(yīng)用程序的具體情況，但是一般情況下與圖 2 相似。 圖 2. 客戶機(jī)通過 HTTP 請求動態(tài)頁面 與前一個示例中的客戶機(jī)一樣， 圖 2 中的客戶機(jī)首先發(fā)出一個請求。靜態(tài)請求和動態(tài)請求之間實際上沒什么差異（有時候 .php 或 .cgi 等擴(kuò)展名可能意味著動態(tài)請求，但是它們可能引起誤解）。如何處理請求是由 WEB 服務(wù)器決定的。 在 圖 2 中，請求被發(fā)送到一個應(yīng)用服務(wù)器，比如運行一個 Java? 應(yīng)用程序的 Solaris 系統(tǒng)。應(yīng)用服務(wù)器執(zhí)行一些處理，然后向數(shù)據(jù)庫查詢更多的信息。得到這些信息之后，應(yīng)用服務(wù)器生成一個 HTML 頁面，這個頁面 由 WEB 服務(wù)器轉(zhuǎn)發(fā)給客戶機(jī)。因此，這個請求的服務(wù)時間是幾個部分的總和。如果數(shù)據(jù)庫訪問花費 7ms，應(yīng)用服務(wù)器花費 13ms， WEB 服務(wù)器花費 5ms，那么網(wǎng)頁的服務(wù)時間就是 25ms。根據(jù)前面介紹的倒數(shù)規(guī)則，XX 學(xué)院畢業(yè)論文（設(shè)計） 12 各個組件的容量分別是每秒 14 77 和 200 個請求。因此，瓶頸是應(yīng)用服務(wù)器，它使這個系統(tǒng)每秒只能處理 77 個連接；超過這個數(shù)量之后， WEB 服務(wù)器被迫等待，連接開始排隊。通過這些示例可以得出以下結(jié)論： 在用戶發(fā)出請求和獲得最終頁面之間的步驟越多，整個過程就越慢，系統(tǒng)容量就越低 。 隨著頁面請 求速率的增加，這種效應(yīng)會越來越顯著。在項目開始時做出的體系結(jié)構(gòu)決策也會影響站點處理負(fù)載的能力。 用于動態(tài)站點的 N 層體系結(jié)構(gòu) 。 應(yīng)用程序（包括 WEB 應(yīng)用程序）的體系結(jié)構(gòu)常常按照層來描述。靜態(tài)站點可以被看作只有 一層 —— WEB 服務(wù)器。如果用 WEB 服務(wù)器運行某種腳本語言（比如 PHP），從而連接數(shù)據(jù)庫，那么這可以看作 兩層 。前一節(jié)中的示例有 三層 ， 即前端 WEB 服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫。 一個軟件也可能由多層組成，這取決于您談話的對象。例如， PHP 腳本可能使用一個模板引擎把業(yè)務(wù)邏輯與表示分隔開，它可 以被看作單獨的兩層。 Java 應(yīng)用程序可能通過 Java servlet 執(zhí)行表示任務(wù)， servlet 通過與 Enterprise Java Bean (EJB) 通信執(zhí)行業(yè)務(wù)邏輯， EJB 通過連接數(shù)據(jù)庫獲取更多信息。因此，換一個角度來看，三層體系結(jié)構(gòu)可能是另一副樣子，尤其是在涉及不同的工具集時。 常見的體系結(jié)構(gòu) 盡管應(yīng)用程序的體系結(jié)構(gòu)各不相同，但是有一些常見的體系結(jié)構(gòu)趨勢。在一般情況下，應(yīng)用程序需要四個功能層： 客戶機(jī)層 表示層 業(yè)務(wù)邏輯層 數(shù)據(jù)層 在 WEB 應(yīng)用程序中，客戶機(jī)層由 WEB 瀏覽器處理。瀏覽器顯示 HTML 并執(zhí)行 Javascript（以及 Java applet、 ActiveX 或 Flash applet），從而向用戶顯示信息和收集用戶信息。表示層是從服務(wù)器到客戶機(jī)的接口，它負(fù)責(zé)控制輸出的格式，讓輸出可以在客戶機(jī)上顯示。業(yè)務(wù)邏輯層實施業(yè)務(wù)規(guī)則（比如計算和工作流），從而驅(qū)動應(yīng)用程序。最后，數(shù)據(jù)訪問層是持久化的數(shù)據(jù)存儲，比如數(shù)據(jù)庫或文件存儲。 大多數(shù)應(yīng)用程序需要所有這四層的功能，盡管它們可能不需要明顯完整地實現(xiàn)這些層。 另一種流行的體系結(jié)構(gòu)是 ModelViewController，這是一種用于分隔應(yīng)用程序組件的模式。在 MVC 模式中，模型封裝業(yè)務(wù)邏輯層，并與框架一起封裝數(shù)據(jù)層。視圖負(fù)責(zé)處理發(fā)送給客戶機(jī)的數(shù)據(jù)表示?？刂破鞯淖饔檬强刂茟?yīng)用程序流程。 層的容量擴(kuò)展 。 WEB 應(yīng)用程序的容量意味著讓它能夠處理更多的通信流。容量擴(kuò)展的一個方面是如何根據(jù)需求部署硬件。另一個方面是應(yīng)用程序如何響應(yīng)新的硬件環(huán)境。從概念上說，在出現(xiàn)性能問題時，往往首先想到使用功能更強(qiáng)的服務(wù)器；但是應(yīng)用程序本身很可能造成其他瓶頸。把應(yīng)用程序劃分為一系列層有助于收縮問題的范圍，可以簡化容量擴(kuò)展。 對 WEB 應(yīng)用程序進(jìn)行性能調(diào)優(yōu) 13 數(shù)據(jù) 庫是另一個常常適合使用垂直擴(kuò)展的場合。讓數(shù)據(jù)集跨越不同的服務(wù)器需要在應(yīng)用程序?qū)幼龃罅抗ぷ?，比如跨兩個數(shù)據(jù)庫聯(lián)結(jié)列并確保數(shù)據(jù)是一致的。使用更強(qiáng)大的數(shù)據(jù)庫服 務(wù)器要容易得多，而且不需要通過重新構(gòu)建應(yīng)用程序來支持分散的數(shù)據(jù) 把 WEB 應(yīng)用程序建模為隊列 。 根據(jù)前面對應(yīng)用程序體系結(jié)構(gòu)的討論可以看出， WEB 請求會通過多個階段，每個階段花費一定的執(zhí)行時間。請求排隊通過每個步驟，完成一個步驟之后，再排隊進(jìn)入下一個步驟。每個步驟很像人們在商店里排隊結(jié)帳的情況。 可以把 WEB 應(yīng)用程序建模為一系列步驟（稱為 “ 隊列 ” ）。應(yīng) 用程序的每個組件都是一個隊列。建模為一系列隊列的典型 WEBSphere 應(yīng)用程序如圖 3 所示 ： 圖 3. 建模為排隊網(wǎng)絡(luò)的 WEBSphere174。 應(yīng)用程序 圖 3 顯示請求等待 WEB 服務(wù)器處理它們，然后等待 WEB 容器，依此類推。如果進(jìn)入某個隊列的請求速率超過了此 隊列處理請求的速率，請求就會聚集起來。當(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)整請求的次序以降低尋道時間。另一個隊列是運行隊列，其中包含等待運行的進(jìn)程的有序列表。應(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 客戶機(jī)的連接，并在應(yīng)用服務(wù)器空閑時發(fā)出請求。應(yīng)用服務(wù)器只需處理它能夠及時派發(fā)的請求。 針對開發(fā)人員的提示 作為開發(fā)人員，應(yīng)該按照一些一般原則提高應(yīng)用程序的可伸縮性。這些原則可以應(yīng)用于大多數(shù) WEB 應(yīng)用程序。 XX 學(xué)院畢業(yè)論文（設(shè)計） 14 應(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ā)生的情況，這是擴(kuò)展站點容量的關(guān)鍵。您認(rèn)為不夠優(yōu)化的代碼部分可能不會造成問題。只有通過適當(dāng)?shù)亩攘?，才能發(fā)現(xiàn)真正的瓶頸。 WEB 在本質(zhì)上是無狀態(tài)的。用戶發(fā)出的每個請求都獨立于以前的請求。但是，應(yīng)用程序常常是有狀態(tài)的。用戶必須登錄應(yīng)用程序以證明自己的身份，在訪問站點期間可能要維護(hù)購物車的狀態(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ā)送回客戶機(jī)，這樣就不需要在本地存儲會話。在用戶的 cookie 中能夠存儲的數(shù)據(jù)量是有限的，但是 RFC 2109 規(guī)定客戶機(jī)應(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)用程序負(fù)責(zé)生成包含 ESI 標(biāo)記的 HTML 文檔，還負(fù)責(zé)生成組件。 WEB 應(yīng)用程序前面的代理緩存根據(jù)各個部分重新組裝最終的文檔，負(fù)責(zé)緩存一些組件并為其他組件發(fā)出請求。清單 1 給出一個 ESI 文檔示例。結(jié)束語 15 結(jié)束語 筆者結(jié)合 A 企業(yè)的實際需求 , 對 WEB 應(yīng)用系統(tǒng)的主要技術(shù)支持層面進(jìn)行了探討 , 提出了基于 WEB 的三層網(wǎng)絡(luò)計算模式為基礎(chǔ)的 W EB 應(yīng)用系統(tǒng)技術(shù)支持平臺 , 該方案的實施為企業(yè)實現(xiàn)前后臺數(shù)據(jù)交換、整 合內(nèi)外部資源、協(xié)調(diào)和改進(jìn)業(yè)務(wù)流程、實現(xiàn)其 WEB 理念 , 提供了有效的技術(shù)支持。 A 企業(yè)原先存在的信息交互和共享困難、對客戶的請求反應(yīng)遲鈍、 W EB 決策支持不力等現(xiàn)象得到了明顯的改善。在國家壓縮投資規(guī)模的宏觀調(diào)控背景下 , 2021 年上半年該企業(yè)產(chǎn)品銷售收入與凈利潤均同比增長了 30% 以上 , 其 WEB 應(yīng)用系統(tǒng)發(fā)揮了重要作用。 XX 學(xué)院畢業(yè)論文（設(shè)計） 16 致 謝 走出畢業(yè)論文的千頭萬緒，接下來便是自然而然的驀然回首。于是，幾多往事歷歷在目，一絲傷感輕輕劃過，無限感動激蕩心頭。誠然，更多的感激注定只能駐扎在心底，但還是禁不住嘗試有 些呆板的文字表述。 首先，我要鄭重地感謝我的導(dǎo)師。自我因個人興趣而選擇本論文主題開始， 老師 便給予充分的理解和支持，就論文的立意選材、謀篇布局做了必不可少的指導(dǎo)，老師對學(xué)術(shù)的敏銳以及思路的開闊為本文的順利完成提供了富有成效的保證。即便 老師一邊忙著給本科班上課一邊備課 ，但仍然多次通過電話和 em a il 督促、指導(dǎo)論文的寫作，其嚴(yán)謹(jǐn)和負(fù)責(zé)，讓一度偷懶懈怠的我倍為感動，也深感慚愧。 “師者，傳道授業(yè)解惑也。 ”從老師身上，我深刻地領(lǐng)略到這句話的精彩內(nèi)涵。在過去兩年多的學(xué)習(xí)和生活中，尤其是當(dāng)我遇到挫折、陷入迷茫或者做錯事 時，老師總是以師者的智慧、長輩的寬容、朋友的坦誠，給我難能可貴的指點和幫助。為遇到這樣的導(dǎo)師而感到慶幸。 最后，我必須要感謝我的家人。 “吾本寒家 ”，感謝我的父母含辛茹苦、無怨無悔地把我撫養(yǎng)、栽培到現(xiàn)在；家人永遠(yuǎn)是我的依托，也是鞭策我不斷前進(jìn)的力量。 有人說，時間如流水，一刻不停地沖刷著記憶，但是，有些記憶隨著時間的沖刷不會消逝，反而會變得越來越清晰、越來越值得回味，因為它們已深深銘刻在內(nèi)心深處。兩年多的財大求學(xué)即將劃上句號，收拾行囊、開始新征途的日子悄然逼近，回頭看看走過的路，無限感慨，揮揮手，卻依然不想說 再見 ！ 致謝 17 參考 文獻(xiàn) [1] 鄭剛 .基于 B/S 模式的網(wǎng)上教學(xué)系統(tǒng)研究與設(shè)計 [J].計算 機(jī)工程與應(yīng)用 .。 [2] 汪云 ,等 .基于 B/S 模式的學(xué)生信息管理系統(tǒng) [J].襄樊學(xué)院報 ,2021,27(2)。 [3] 張念魯 ,劉紅屏 .WEB 程序設(shè)計教程 [M].高等教育出版社 ,。 [4] 宣小平 ,但正剛 ,張文藝 .ASP 數(shù)據(jù)庫系統(tǒng)開發(fā)實例導(dǎo)航[M].人民郵電出版社 ,。 [5] 丁貴廣 ,閆允一 ,孟繁杰 .ASP及 [M].機(jī)械工業(yè)出版社 ,。 [6]