【導讀】要有一個性能健全的Web網站。站在同時接受如此多用戶的訪問時候能否負荷的了。一種全局性的信息結構，它將文檔中的不同部分通過關鍵字建立鏈接，使信息得以用交互方式搜索。它是超級文本的簡稱。超媒體是超文本和多媒體在信息瀏覽環(huán)境下的結合。是超級媒體的簡稱。活一段聲音，顯示一個圖形，甚至可以播放一段動畫。WEB就是一種超文本信息系統(tǒng)，WEB的一個主要的概。念就是超文本連接，它使得文本不再象一本書一樣是固定的線性的?？梢詮囊粋€位置跳到另外的位置?？梢詮闹蝎@取更多的信息。想要了解某一個主題的內容只要在這個主題上點一下，就可以。跳轉到包含這一主題的文檔上。正是這種多連接性把它稱為WEB。這是一個類似維基百科的超文本在線編輯數據庫。

　　

【正文】 隊列 ” ）。應 用程序的每個組件都是一個隊列。建模為一系列隊列的典型 WEBSphere 應用程序如圖 3 所示 ： 圖 3. 建模為排隊網絡的 WEBSphere174。 應用程序 圖 3 顯示請求等待 WEB 服務器處理它們，然后等待 WEB 容器，依此類推。如果進入某個隊列的請求速率超過了此 隊列處理請求的速率，請求就會聚集起來。當出現請求聚集時，服務時間是不可預測的，用戶會察覺到瀏覽器會話延遲。 圖 3 中的隊列代表最糟糕的情況，因為 WEB 服務器可以自己處理一些請求，即不需要訪問數據庫。 隊列在 UNIX174。 環(huán)境中很常見。當應用程序發(fā)出磁盤請求的速率快于磁盤返回數據的速率時，操作系統(tǒng)會讓磁盤請 求排隊，還可能調整請求的次序以降低尋道時間。另一個隊列是運行隊列，其中包含等待運行的進程的有序列表。應用程序會等待輪到它們使用某些有限的資源（比如 CPU）。 因此，隊列調優(yōu)是一種平衡的藝術。隊列太小，就會在仍然有富余容量的情況下拒絕用戶。隊列太大，就會試圖為過多的用戶提供服務，導致性能很差。 導致情況更復雜的另一個因素是，這些排隊位置并不是無成本的。保留排隊位置會導致內存開銷，對于應用服務器，這會與正在處理請求的線程爭用內存。因此，在一般情況下，在應用服務器上排隊并不是好方法。推薦的方法是在應用服務器之前 （比如在 WEB 服務器上）排隊。這意味著 WEB 服務器要保持與 WEB 客戶機的連接，并在應用服務器空閑時發(fā)出請求。應用服務器只需處理它能夠及時派發(fā)的請求。 針對開發(fā)人員的提示 作為開發(fā)人員，應該按照一些一般原則提高應用程序的可伸縮性。這些原則可以應用于大多數 WEB 應用程序。 XX 學院畢業(yè)論文（設計） 14 應用程序應該以某種方式向收集系統(tǒng)提供度量值（即使收集系統(tǒng)僅僅是日志文件）。這些度量值包括訪問應用程序中某個函數的頻率或處理一個請求花費的時間等。這并不會使應用程序運行得更快，但是有助于了解應用程序為什么會變慢以及 代碼的哪些部分花費的時間最長。了解什么時候調用某些函數，這有助于把在系統(tǒng)上觀察到的現象（比如 CPU 忙或磁盤活動量高）與應用程序中的活動（比如上傳圖像）聯系起來。 能夠了解站點上發(fā)生的情況，這是擴展站點容量的關鍵。您認為不夠優(yōu)化的代碼部分可能不會造成問題。只有通過適當的度量，才能發(fā)現真正的瓶頸。 WEB 在本質上是無狀態(tài)的。用戶發(fā)出的每個請求都獨立于以前的請求。但是，應用程序常常是有狀態(tài)的。用戶必須登錄應用程序以證明自己的身份，在訪問站點期間可能要維護購物車的狀態(tài)，還可能要填寫供以后使用的個人信息。跟蹤會 話是一種成本很高的操作，尤其是在涉及多個服務器的情況下。 在單一服務器上運行的 WEB 應用程序可以把會話信息放在內存中，在服務器上運行的任何 WEB 應用程序實例都可以訪問共享內存。常常會給用戶分配一個標志，這個標志標識內存中的會話。考慮一下在涉及第二個應用服務器時會發(fā)生什么。如果用戶的第一個請求發(fā)送給一個服務器，第二個請求發(fā)送給另一個服務器，那么會存在兩個單獨的會話，它們并不相同。 此問題的常用解決方案是，把會話存儲在數據庫而不是內存中。這種方法導致的問題是，對于每個請求，需要增加數據庫讀操作，還可能涉 及數據庫寫操作。每個 WEB 應用服務器都需要這個數據庫。 一個解決方案是，只在需要會話的地方使用會話。應用程序并不為每個請求裝載會話，而是只在需要會話時裝載會話。這會減少對后端數據庫的請求數量。 另一個方法是加密會話數據并把它發(fā)送回客戶機，這樣就不需要在本地存儲會話。在用戶的 cookie 中能夠存儲的數據量是有限的，但是 RFC 2109 規(guī)定客戶機應該能夠為每個域名存儲至少 20 個 cookie，每個 cookie 至少可以保存 4K 字節(jié)的數據。 與其他部分相比，應用程序的某些部分會更頻繁地修改數 據。新聞網站可能每個月只修改頂級分類列表一次。因此，對于每個請求都通過查詢數據庫獲取最新的分類列表是很浪費的。同樣，包含新聞稿的頁面在其整個生命周期中可能只修改一兩次，所以不需要為每個請求重新生成它。 緩存意味著把處理成本很高的請求的結果存儲起來，供以后使用?？梢跃彺娣诸惲斜砘蛘麄€頁面。 在尋找應該緩存的數據時，還應該考慮是否確實需要直接提供這些信息。需要在每個頁面上顯示用戶的購物車嗎？只顯示總金額怎么樣？或者只顯示一個簡單的鏈接 “view the contents of your cart” 。 EdgeSide Includes (ESI) 是一種標記語言，可以用它把網頁劃分為單獨的可緩存的實體。應用程序負責生成包含 ESI 標記的 HTML 文檔，還負責生成組件。 WEB 應用程序前面的代理緩存根據各個部分重新組裝最終的文檔，負責緩存一些組件并為其他組件發(fā)出請求。清單 1 給出一個 ESI 文檔示例。結 束 語 15 結束語 筆者結合 A 企業(yè)的實際需求 , 對 WEB 應用系統(tǒng)的主要技術支持層面進行了探討 , 提出了基于 WEB 的三層網絡計算模式為基礎的 WEB 應用系統(tǒng)技術支持平臺 , 該方案的實施為企業(yè)實現前后臺數據交換、整 合內外部資源、協(xié)調和改進業(yè)務流程、實現其 WEB 理念 , 提供了有效的技術支持。 A 企業(yè)原先存在的信息交互和共享困難、對客戶的請求反應遲鈍、 WEB 決策支持不力等現象得到了明顯的改善。在國家壓縮投資規(guī)模的宏觀調控背景下 , 2020 年上半年該企業(yè)產品銷售收入與凈利潤均同比增長了 30% 以上 , 其 WEB 應用系統(tǒng)發(fā)揮了重要作用。 XX 學院畢業(yè)論文（設計） 16 致 謝 走出畢業(yè)論文的千頭萬緒，接下來便是自然而然的驀然回首。于是，幾多往事歷歷在目，一絲傷感輕輕劃過，無限感動激蕩心頭。誠然，更多的感激注定只能駐扎在心底，但還是禁不住嘗試有 些呆板的文字表述。 首先，我要鄭重地感謝我的導師。自我因個人興趣而選擇本論文主題開始， 老師 便給予充分的理解和支持，就論文的立意選材、謀篇布局做了必不可少的指導，老師對學術的敏銳以及思路的開闊為本文的順利完成提供了富有成效的保證。即便 老師一邊忙著給本科班上課一邊備課 ，但仍然多次通過電話和 督促、指導論文的寫作，其嚴謹和負責，讓一度偷懶懈怠的我倍為感動，也深感慚愧。 “師者，傳道授業(yè)解惑也。 ”從老師身上，我深刻地領略到這句話的精彩內涵。在過去兩年多的學習和生活中，尤其是當我遇到挫折、陷入迷?；蛘咦鲥e事 時，老師總是以師者的智慧、長輩的寬容、朋友的坦誠，給我難能可貴的指點和幫助。為遇到這樣的導師而感到慶幸。 最后，我必須要感謝我的家人。 “吾本寒家 ”，感謝我的父母含辛茹苦、無怨無悔地把我撫養(yǎng)、栽培到現在；家人永遠是我的依托，也是鞭策我不斷前進的力量。 有人說，時間如流水，一刻不停地沖刷著記憶，但是，有些記憶隨著時間的沖刷不會消逝，反而會變得越來越清晰、越來越值得回味，因為它們已深深銘刻在內心深處。兩年多的財大求學即將劃上句號，收拾行囊、開始新征途的日子悄然逼近，回頭看看走過的路，無限感慨，揮揮手，卻依然不想說 再見 ！ 參考文獻 17 參考 文獻 [1] 鄭剛 .基于 B/S 模式的網上教學系統(tǒng)研究與設計 [J].計算 機工程與應用 .。 [2] 汪云 ,等 .基于 B/S 模式的學生信息管理系統(tǒng) [J].襄樊學院報 ,2020,27(2)。 [3] 張念魯 ,劉紅屏 .WEB 程序設計教程 [M].高等教育出版社 ,。 [4] 宣小平 ,但正剛 ,張文藝 .ASP 數據庫系統(tǒng)開發(fā)實例導航[M].人民郵電出版社 ,。 [5] 丁貴廣 ,閆允一 ,孟繁杰 .ASP及 [M].機械工業(yè)出版社 ,。 [6] 薛元昀 ,顧佳霙 ,文信達 .網頁數據庫設計與發(fā)布 [M].清華大學出版社 ,。