簡介
網絡對整體
響應時間的影響是是通過不同機制完成的。所選擇的協議(例如幀中繼或ATM，EIGRP或OSPF)會很大程度地影響數據在網絡中傳輸的延遲時間。這些時間包括處理的時延(主機接收到數據包并獲得各種信息), 排隊時延(當出現了其它的信息包時)，傳送或連續傳輸時延(傳輸幀中的第一位和最后一位的時間), 傳輸時延(一個數據位通過鏈路的時間，他取決于物理的介質和距離)。包的損壞和丟失也會降低信息的質量或增加額外的時延，因為需要重新傳輸。地面傳輸的企業網絡，等待和傳輸時延是網絡時延的主要問題。對于衛星網絡，傳輸時延(加上訪問協議)是主要問題。服務器時延的影響有服務器本身和應用設計兩個方面。服務器本身的性能包括處理器的速度，
存儲器和I/O性能，硬盤驅動速度以及其它設置。應用設計包括結構和算法。
結構
應用時延受幾個獨立的因素影響，例如應用設計(例如通話的穩定性)，交易的大小，選擇的協議(例如
UDP或TCP)，以及網絡的結構。完成一個確定的交易時，一個應用所需要的往返次數越少，它受到網絡結構的影響也越小。然而，由于需要重新傳輸，所以往返的次數本身可能取決于網絡結構。
用戶的經驗
計算機的用戶最討厭等待。在大量的處理環境中，超過3秒以上的響應時間將會嚴重影響工作效率。然而最終用戶的感受不僅僅是絕對時間問題，他們對于響應時間的期望是參照以往的經驗，而這種期望是相對于他們使用該應用的基準性能。如果使用該應用的當前感受和以往的經驗有很大的差別時，抱怨以及需要支持的電話就會成倍地增加。
重要性
應用響應時間的問題隨著基于服務器應用的大量增加而迅速增多。確定造成應用延遲的原因成為很困難的任務。財富500強中一個財務公司的網絡管理經理說他們花了太多的時間用來查找問題，該經理補充說：“甚至技術人員已經把故障確定為網絡中問題的情況下，也只有50%的情況真是網絡的問題。有時我們不得不將所有人都派出去而只是為了找到問題在哪里”。
維護和管理
企業要求其網絡，應用以及MIS的經理要保證那些與業務相關的關鍵應用必須在網絡上平穩運行。確定影響應用性能的問題在哪里以及誰負責解決該問題是IT部門面臨的十分費時且具有挑戰性的工作。由于缺少有經驗的人員和人力資源的限制，所有企業都希望以省時省力的方法來維護和管理響應時間。
[1-2]2操作系統編輯
操作系統的反映時間
在操作系統中，響應時間指用戶發出請求或者指令到系統做出反應（響應）的時間。
系統響應時間包括兩個方面：
時間長度和時間的易變性。用戶響應時間應該適中，系統響應時間過長，用戶就會感到不安和沮喪，而響應時間過短有時會造成用戶加快操作節奏，從而導致錯誤。系統響應時間的易變性是指相對于平均響應時間的偏差。即使響應時間比較長，低的響應時間易變性也有助于用戶建立穩定的節奏。因此在系統響應時間上堅持如下原則：
響應時間長度 界面設計
0-10 秒 鼠 標 顯 示 成 為 沙 漏
10 到18 秒 由微幫助來顯示處理進度
18 秒 以 上 顯示處理窗口，或顯示進度條
一個長時間的處理完成時 應給予完成警告信息
從用戶角度來說，軟件性能就是軟件對用戶操作的響應時間。說得更明確一點，對用戶來說，當用戶單擊一個按鈕，發出一條指令或在web頁面上單擊一個鏈接，從用戶單擊開始到應用系統把本次操作的結果以用戶能察覺的方式展示出來，這個過程所消耗的時間就是用戶對軟件性能的直觀印象。
響應時間過程分析
我們需要對這個過程進行分解，才能得到你真正想要的響應時間。我把整個過程分三個部分，呈現時間，數據傳輸時間和系統處理時間。
呈現時間
其實主要說的瀏覽器對接收到數據的一個處理展示的過程。幾年前大家都在用IE，如果頁面顯示比較慢，我們肯定不會怪罪IE，只會怪罪電信運營商的網速或被訪問的系統（其實，大多情況我們不會考慮是被訪問系統的問題）。現在chrome來了，我們會發現同一臺電腦同一個網站，通過chrome去訪問，頁面的呈現速度會比IE略快。這是各種評測及大眾用戶的整體感受。當然，我個人感覺，opera瀏覽器的呈現速度最快，但它的顯示效果一直不太好。
當然，我說這個呈現時間總不能全怪罪與瀏覽器的身上吧！當然還和承載它的操作系統有關，以及電腦硬件（比如cpu 內存）。假如你有超快的瀏覽器，如果是一臺極其垃圾的電腦，我想你多打開兩個網頁就有可能使電腦卡掉。
數據傳輸時間
千萬不要忽視數據傳輸時間。如果你要寄信給你一個遠方的朋友，你想是什么影響你將信息傳遞給遠方的朋友？不是你寫信的過程（如果你寫的信不像書一樣厚的話），也不是你朋友讀信的過程，而是送信的過程。（ps, 我10天前在china-pub訂購的一本書現在還沒到貨！XXX）
拿我們系統的數據傳輸過程來說，我們發送一個請求需要時間，系統處理完后返回給我們也需要時間。初學性能測試工具的同學喜歡拿工具去測試互聯網上的一些系統，甚至不懂性能的同學認為可以用性能測試工具將互聯網上的一些網站壓崩潰。貌似這一招比任何黑客攻擊厲害多去。
那么，我覺得這些同學應該補補網絡知識了，你的帶寬是多少？互聯網是個網，就是算是相同的起點與終點，它有可能走的不同的路線。有沒有考慮網絡延遲？就算你的并發請求都能成功的發出，但到目的地的時候，已經不能叫并發了。
這也是為什么我們在一般做性能測試時，一般要強調要在局域網中進行。當然，也有特殊的性能測試需要在互聯網中時行。它們重點不是求用戶的最大的并發量。
系統處理時間
系統得到請求后對請求進行處理并將結果返回。那我進行性能測試主要就是驗證系統的處理時間，因為前面的呈現時間和數據傳輸時間都我們不可控制的，用戶使用的電腦及瀏覽器千差萬別，用戶的網絡狀況千差萬別。我們唯一能控制的就是將系統的處理請求的時間縮到最短暫。
如果我們對系統的的處理進行分析和講解的話，它會是一個非常龐大與復雜的過程。語言、語言框架、中間件，數據庫、系統架構以及服務器系統。所以，想成為一個優秀的性能測試工程師我們的路還很長。
實際性的能測試
聽了上面的分析，貌似每個過程都挺“浪費”時間，那么我們如何只測試系統的處理時間呢？
其實現在的測試工具都屏蔽呈現過程，只是模擬多用戶并發請求，計算用戶得到響應的時間，頁不會將服務器的每個響應都向客戶端呈現。
對于數據傳輸的問題，這也是我要強調的性能測試要在局域網中進行，在局域網中一般不會受到數據帶寬的限制。所以，可以對數據的傳輸時間忽略不計。
響應時間的定義：
響應時間
指的是客戶發出請求到得到響應的整個過程的時間。在某些工具中，請求響應時間通常會被稱為“TTLB”(Time to laster byte) ,意思是從發起一個請求開始，到客戶端收到最后一個字節的響應所耗費的時間。
系統響應時間
應用系統從發出請求開始到客戶端接收到響應所消耗的時間。需要注明的是，這樣的定義完全是個人喜好。你可以提異議。
我們來看兩種情況：
我要訪問百度首頁，發出了一個請求，百度開始給我返回頁面數據，當搜索框與搜索按鈕都已經返回到頁面上了，但那個圖標還在發送中。我不認為這個響應是完整的。必須把頁面上的所有信息都返回給我才是完整的，我要的也是所有結果返回給我的時間。這種情況更符合“相應時間”的定義
某系統有一個信息查詢功能，當我輸入某條件查詢時，可能要查詢幾百萬條數據，如果數據庫，要查詢所有的數據并把所有的數據全部完整的返回給我。可能服務器要查詢很久，而我的電腦全部接收這些數據也可能只直接掛掉。那么服務器可能只查詢100條數據并把數據返回給我，當我點擊“下一頁”時，服務器再次查詢并將第二頁的數據返回給我。這種情況更符合“系統響應時間”的定義。
關于響應時間，要特別說明的一點是，對客戶來說，該值是否能夠被接受是帶有一定的用戶主觀色彩，也就是說，響應時間的“長”和“短”沒有絕對的區別。
合理的響應時間
在互聯網上對于用戶響應時間，有一個普遍的標準。2/5/10秒原則。
也就是說，在2秒之內給客戶響應被用戶認為是“非常有吸引力”的用戶體驗。在5秒之內響應客戶被認為“比較不錯”的用戶體驗，在10秒內給用戶響應被認為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應，那么大多用戶會認為這次請求是失敗的。
這里我們還要考慮一個使用頻率的概念。
我最早安裝windows系統可能要1個小時，我們為什么覺得這很正常，因為我們要很久才裝一次系統，如果系統使用得當，可能一個系統用幾年不用重裝，假如，我們在系統上裝個任何小軟件都要這么長時間，那我們一定是無法忍受的。對于軟件控來說，他們會時常安裝各種新鮮有趣的軟件進行使用。
對于一個稅務報賬系統，該系統的用戶每月使用一次，一次花費3小時進行數據的錄入，
當用戶單擊“提交”按鈕后，即使系統在10分鐘后才給出“處理成功”的消息，我們也覺得是可以接受的。
因此，在進行性能測試時，“合理的響應時間”取決于用戶的需求，而不能依據測試人員自己設想來決定。