【正文】 bps廣域網(wǎng)鏈路應(yīng)該要更新在部署此項應(yīng)用之前。實驗七ＴＣＰ窗口大小在文件傳送過程中的影響實驗?zāi)康模赫故続CE怎樣診斷和想象應(yīng)用和網(wǎng)絡(luò)問題；他不是一步一步的輔導(dǎo)。如果你有ACE的經(jīng)驗,你能通過上一頁方面的說明再創(chuàng)造研究。在這例子中銀幕圖象是在ADM安裝運行ACE的同時,被捕獲，若沒有安裝ADM一些銀幕可以看起來不同；可能緩慢反應(yīng)時間的原因陷入兩個通用的范疇 ：網(wǎng)絡(luò)瓶頸和服務(wù)器瓶頸。這個研究研究,識別出性能問題的原因并提出建議可能的解決方案實驗內(nèi)容：2. 帶寬影響3. 協(xié)議影響實驗步驟：一、 ACE分析在記錄導(dǎo)入ACE之后,我們在數(shù)據(jù)交流圖中看事務(wù)方面, 這體現(xiàn)了數(shù)據(jù)交換的流動層應(yīng)用之間的消息；如圖71圖71 數(shù)據(jù)交換表數(shù)據(jù)交流圖顯示的數(shù)據(jù)交換的客戶端啟動文件傳輸和服務(wù)器響應(yīng)與一些大型(1460 bytes或者更高)應(yīng)用信息,正如被藍(lán)色箭頭代表的客戶端和FTP_Server層之間。當(dāng)我們檢查顯示依賴性盒、ACE顯示, networkrelated時延,正如表明FTP_Server層紫色的三角形?？s放一組應(yīng)用信息并顯示對應(yīng)用信息圖和網(wǎng)絡(luò)數(shù)據(jù)包圖可以讓我們來考察網(wǎng)絡(luò)數(shù)據(jù)包和應(yīng)用信息之間的關(guān)系。如圖72圖72 網(wǎng)絡(luò)數(shù)據(jù)包圖表如同按照網(wǎng)絡(luò)注意到那樣,網(wǎng)絡(luò)數(shù)據(jù)包圖展示是以小包交換作業(yè)。應(yīng)用信息圖顯示作業(yè)信息作為一種應(yīng)用層的情況下互相交換了信件,不包括從細(xì)節(jié)下面的應(yīng)用層。我們可以看到FTP服務(wù)器發(fā)送數(shù)據(jù)包給客戶，并等待確認(rèn)通知的到達(dá)在派遣更多的應(yīng)用的數(shù)據(jù)之前。這不是最佳的行為,因為它延伸的文件傳輸。從數(shù)據(jù)交換圖,我們也可以畫圖表示具體的統(tǒng)計和我們診斷有關(guān)的事務(wù)。我們知道延遲是網(wǎng)絡(luò)相關(guān),但是我們希望看到帶寬如何被使用在這個文件傳輸期間。如圖73；圖73 網(wǎng)絡(luò)吞吐量統(tǒng)計量以上的網(wǎng)絡(luò)的吞吐量統(tǒng)計數(shù)據(jù)表明,最大的下載速度是大約350 Kbps,遠(yuǎn)遠(yuǎn)低于環(huán)路提供的1,544Mbps。；圖74 文件下載延時圖表辨認(rèn)出協(xié)議延遲作為主要來源在這個文件傳輸。從這個圖，我們也能下鉆進(jìn)協(xié)議延遲和查看一個圖形化分析可能引起這個特定的延遲的不同因素。應(yīng)用延遲（客戶/服務(wù)器處理時間）對與事務(wù)是微不足道的，在這個情況中，網(wǎng)絡(luò)是緩慢應(yīng)用反應(yīng)時間的原因。AppDoctor診斷的提供了一個可能的瓶頸更為顆粒的分析。這個功能測試當(dāng)前事務(wù)反對因素,常常會造成在基于網(wǎng)絡(luò)的應(yīng)用性能方面的問題。越過指定的門檻值作為瓶頸或潛在的瓶頸。如圖75；圖75 文件下載診斷，每一個的描述在下面二、帶寬影響數(shù)據(jù)包傳送延遲是一個包大小的功能。更低傳送速度引起更大的延遲。這個值是總的延遲由于傳送速度，正如一定百分比的整體應(yīng)用響應(yīng)時間。三、協(xié)議影響網(wǎng)絡(luò)協(xié)議(如TCP)經(jīng)常進(jìn)行流量控制,擁塞控制等方面不同,這可能油門的速率發(fā)送數(shù)據(jù)的應(yīng)用。其它協(xié)議的影響,也直接影響應(yīng)用程序的性能包括重傳和碰撞。這個值是其總的延遲因協(xié)議的影響,表示為一定百分比的整體應(yīng)用響應(yīng)時間。四、TCP窗口影響當(dāng)一個應(yīng)用是發(fā)大量數(shù)據(jù)在一個高帶寬和highlatency網(wǎng)絡(luò),TCP窗口要足夠大以允許TCP發(fā)送很多數(shù)據(jù)包在一排而無需等待TCP的確認(rèn)。TCP將要發(fā)送數(shù)據(jù)，只有發(fā)送但還沒確認(rèn)的數(shù)據(jù)的數(shù)量低于最小的擁塞控制窗口，發(fā)送窗口接收窗口大小。1. 發(fā)送者和接收者的窗口有默認(rèn)大小,都可以被一個應(yīng)用程序覆蓋。2. 擁塞控制窗口是動態(tài)窗口由TCP在回應(yīng)重傳和其他因素。3. TCP將被迫等待確認(rèn)如果所有的窗戶都小于“bandwidthdelay產(chǎn)品”。bandwidthdelay產(chǎn)品是（2 *帶寬*傳播時延）TCP是降低的速率的應(yīng)用程序可以發(fā)送數(shù)據(jù),因為一個窗口,它太小了。ACE 自動計算最佳窗口尺寸基于“bandwidthdelay” 作為29,974bytes。見下圖76；圖76 窗口的影響圖顯示TCP是限制未被確認(rèn)、機(jī)上數(shù)據(jù)到大約8 KB雖然理想的視窗大小大約30(KB)。圖77 數(shù)據(jù)流到達(dá)穩(wěn)定狀態(tài)等同于TCP窗口大小ACE診斷這種應(yīng)用事務(wù)的瓶頸的TCP的窗口。上面出現(xiàn)過的數(shù)據(jù)交換表格強(qiáng)調(diào)了該過程。作為一個應(yīng)用程序傳輸數(shù)據(jù),TCP增加允許的,未被確認(rèn)的數(shù)據(jù)的數(shù)量,可被傳送,到TCP窗口尺寸；因為TCP正常情況下會增加吞吐量作為網(wǎng)絡(luò)證明它所能處理的業(yè)務(wù),傳輸?shù)拈_始被稱為“慢啟動?！盩CP窗戶阻止應(yīng)用吞吐量永遠(yuǎn)成長和使網(wǎng)絡(luò)飽和。上面的圖表明,在第6交換,流量已達(dá)到穩(wěn)定狀態(tài)。五、結(jié)論分析顯示,對這筆事務(wù)的客戶發(fā)送窗口大小設(shè)置為8(KB)。窗口保護(hù)網(wǎng)絡(luò)被單一個應(yīng)用達(dá)到飽和,然而在這個例子中,TCP流量控制機(jī)制的起因是不良的文件的下載時間。AppDoctor的診斷表明增加TCP視窗大小到大約30 (KB)。它是不需要增加處理能力,在客戶端或者服務(wù)器層的,也不是必要增加帶寬。上述的任何“解決方案”都將是昂貴的和無效的。ACE允許你解決不良的應(yīng)用性能和定位出潛在的原因。實驗八 用高級邏輯腳本模擬一個應(yīng)用實驗?zāi)康模耗銓⑹褂眠@個ACE Whiteboard腳本API來模型和分析一個饒舌的數(shù)據(jù)庫應(yīng)用程序的變化是如何影響預(yù)期價值預(yù)先擷取響應(yīng)時間。當(dāng)部署完畢后,應(yīng)用服務(wù)器和數(shù)據(jù)庫將被一個MAN(Metro Area Networ)帶著10 Mbps帶寬和1ms的延遲,客戶將會訪問應(yīng)用程序服務(wù)器通過T1連接實驗內(nèi)容：使用這個ACE Whiteboard腳本API來模型應(yīng)用性能用不同的預(yù)先擷取的值。實驗步驟：一、用ACE Whiteboard模擬SQL邏輯模型現(xiàn)在你會使用ACE白板,建立了一系列的請求和響應(yīng)消息發(fā)送被這個數(shù)據(jù)庫應(yīng)用程序。在教程中,承擔(dān)應(yīng)用表現(xiàn)以下行為:1. 每一個請求到數(shù)據(jù)庫是固定大?。?5bytes）2. 每一從數(shù)據(jù)庫反應(yīng)是應(yīng)用經(jīng)常開支的53bytes,每行加上55bytes3. 數(shù)據(jù)庫()花費一固定的量的時間來處理每一請求和發(fā)送反應(yīng)。4. 應(yīng)用服務(wù)器()花費一固定的量的時間來產(chǎn)生每一請求根據(jù)以下步驟可以實現(xiàn)：1. 選擇File Open2. 選擇ACE Whiteboard Files 文件類型3. 選擇文件tutorial_sql_backend在reldir\models\std\tutorial_req\module目錄下單擊OK如圖81；圖81 Data Exchange Chart注意：包含兩個層和零點信息4. 選擇Scripting Declare Parameters；注意有兩個公開的參數(shù)。第一個參數(shù)，num_rows，指定行請求的數(shù)量；第二個參數(shù)，prefetch_count，決定多少行數(shù)據(jù)庫發(fā)送返回為每一個請求。單擊Cancle關(guān)閉Declare Parameters對話框。如圖82；圖82 Declare Parameters圖5. 擇Scripting InitializationBlock，如圖83；圖83 InitializationBlock6. 單擊按鈕QuickPredict ()打開QuickPredict7. 在Bandwidth字段值改為10Mbps8. 字段Latency改變值為1ms9. 點擊Update Results；如圖84圖84 QuickPredict結(jié)果注意：被QuickPredict延遲報道是400 ms,這是由于這樣的事實,即400消息是被發(fā)送,每一種都招致1ms的延遲。10. 點擊Close關(guān)閉QuickPredict11. 選擇File Close關(guān)閉模型。在這一部分里,你檢查ACE Whiteboard文件模擬請求/響應(yīng)模式的在初始化塊用信息動態(tài)創(chuàng)建數(shù)據(jù)庫應(yīng)用程序。因為這愛閑聊的的數(shù)據(jù)庫應(yīng)用程序,你看見成排要求的數(shù)量被預(yù)先擷取統(tǒng)計量等同于請求/響應(yīng)模式的數(shù)量分開，每個請求/響應(yīng)模式由兩個信息。由于每個后續(xù)信息是在相反的方向上,你就能辨別潛伏時間延遲可能潛在地是一種性能的瓶頸?，F(xiàn)在,你將愛閑聊的數(shù)據(jù)庫行為包括在ACE書寫板模型的整個三層上的數(shù)據(jù)庫應(yīng)用程序。 二、在ACE Whiteboard上的應(yīng)用模型1. 選擇File Open2. 選擇文件類型ACE Whiteboard3. 選擇文件tutorial_sql_prefetch在目錄reldir\models\std\tutorial_req\module下然后單擊Open打開文件。4. 選擇File Save As...,然后保存文件作為your_initials_tutorial_sql_prefetch，如圖85；圖85 .數(shù)據(jù)交換圖表注意：這三層書寫板模型包含了邏輯腳本。你將用這種邏輯腳本調(diào)用或鏈接你在上方審查的數(shù)據(jù)庫請求的文件。換句話說,現(xiàn)在在我們在上方審查的文件中應(yīng)用行為將被動態(tài)的加入這文件。從邏輯腳本調(diào)用書寫板文件，你首先需要去聲明子作業(yè)。5選擇Scripting Manage Child Tasks，打開Manage Child Tasks對話框，如圖86；圖86 Manage Child Tasks6. 對話框中點擊Declare Child Tasks...7. 由于你正在聲明一個ACE Whiteboard文件，點擊Continue...8. 選擇文件tutorial_sql_backend在目錄reldir\models\std\tutorial_req\module下然后單擊OK。9. 除了宣布了孩子任務(wù),你可以用這個對話框來指定每層的名字在這孩子任務(wù)涉及到相符合的一層當(dāng)前任務(wù)。在這個例子中,一層的名字寫在孩子任務(wù)已對應(yīng)的名字在直接級當(dāng)前任務(wù)10. 點擊OK關(guān)閉對話框?qū)⒁溄舆壿嬆_本到子任務(wù)：1. 在Data Exchange Chart雙擊在Logic Script圖標(biāo)上2. 增加下面代碼到邏輯腳本。第一行創(chuàng)建一個詞典包含兩個條目。這個腳本用num_rows設(shè)置2000和prefetch_count設(shè)置為2調(diào)用這個作業(yè)Signature: def funame (self, action):child_parameters = {39。num_rows39。:2000, 39。prefetch_count39。:2} (action, 39。39。, True, child_parameters)3. 選擇File Save保存這個邏輯腳本4. 在ACE Whiteboard主窗口中選擇File Save保存文件在這個ACE Whiteboard文件,你聲明了一個孩子任務(wù),然后鏈接這孩子任務(wù)作為邏輯的腳本的組成部分。值得注意的是,你都能夠通過值傳遞把聲明的每一個參數(shù)傳給孩子任務(wù)。三、用QuickPredict決定期望的反應(yīng)時間1. 單擊QuickPredict按鈕打開QuickPredict2. 確信第一層client–Mbps。改變第一層的Latency到10ms3. 改變第二層app_server–db_server的Bandwidth到10Mbps和Latency到1ms；點擊Update Results，如圖87圖87屬性設(shè)置結(jié)果注意：在審查QuickPredict結(jié)果，你可以看到這個應(yīng)用花費多余4seconds檢索2000行從數(shù)據(jù)庫4. 留下QuickPredict窗口打開增加預(yù)先取值從2到50：1. 在Data Exchange Chart里雙擊在Logic Script icon. 上2. 改變prefetch_count從2到503. 選擇File Save保存邏輯腳本4. 再打開的QuickPredict對話框中單擊Update Results；窗口QuickPredict應(yīng)該看起來如下圖88：圖88 改變預(yù)先取值后結(jié)果注意：通過增加預(yù)先擷取數(shù)從2到50的時候,你可以看到一個戲劇性的減少應(yīng)用程序的響應(yīng)時間請求2000行的時候。四、結(jié)論在這一實驗,你使用ACE Whiteboard模擬改變?yōu)橐粋€愛閑聊的預(yù)先擷取計數(shù)的數(shù)據(jù)庫應(yīng)用程序的影響。首先,你創(chuàng)造了一個Whiteboard模型愛閑聊的數(shù)據(jù)庫請求/響應(yīng)模式。然后,你調(diào)用這個任務(wù)在一個第二Whiteboard模型。通過改變參數(shù)的值傳遞給孩子任務(wù),你看那個增加預(yù)先擷取的值導(dǎo)致了更少的要求/應(yīng)答模式,從而減少了處理延遲和潛伏時間延誤。 WORD格式整理