我們在測試過程中有的時候響應時間可以通過客戶端效能測試工具獲得，但是有的時候不能，特別是非同步傳輸的系統，當系統請求發出後系統不是及時響應，而是通過後續的應用獲取資訊，這種情況下現有客戶端效能測試工具很難解決響應時間的衡量。因此在類似於此類測試過程中我們可以通過
ethereal
類似的協議分析工具進行響應時間測量。具體方法如下：
1）找出客戶端與伺服器端通訊的資料標誌，包括特定的請求標誌和響應標誌，主要用來判定系統何時向伺服器發起請求何時回應。
2）準備資料報分析工具，並確定在測量過程中資料報分析工具可以監聽到通訊的資料報
3）保證通訊的完整性，包括客戶端的請求和伺服器端的響應。
4）執行業務同時啟動資料報偵聽工具進行資料報抓取，停止業務操作，延時一段時間停止資料報捕獲；
5）通過之前確定的伺服器通訊標誌，查詢出請求標誌資料報文和響應標誌資料報文；
6）通過找到的資料報文的時間戳相減獲得響應時間，可以多次測量減少誤差。
7）在測量過程中保證時鐘同步。
存在的問題：
1）多使用者併發情況下，由於資料報量非常大很難進行分析，另外不同使用者的請求同樣需要確定標誌位。
2）測量過程繁瑣，現在基本還找不到自動測量的工具，只是通過
ethereal
類似的資料偵聽工具輔助測量。
乙個例項：
**會議外呼響應時間測量
業務描述：**外呼業務客戶端採用了
flex
的富客戶端技術，通過
flash
展現客戶監控功能，與伺服器進行非同步互動，客戶端發出請求後有另外乙個程序通過
getmessage
的方式獲取伺服器上的請求響應訊息。
測量過程：
1）確定外呼標誌位，通過分析發現外呼標誌：
」callout…..」,
也就業務者當客戶端發出此標誌的資料報文時，表示客戶端向伺服器發起外呼請求。響應標誌：
acv.p.a
此標誌表明伺服器返回此標誌意味著呼叫成功。（此過程比較耗時）
2）啟動被測應用，同時啟動
ethereal
監聽伺服器與客戶端通訊的資料報文
3）執行外呼業務，執行完成後，在一定時間後，在這裡延時（
1分鐘）因為要求外呼響應不超過1秒。
4）分析捕獲的資料報文，通過
ethereal
的查詢功能，查詢出外呼標誌和響應標誌，通過時間戳相減獲取響應時間。
5）多次測量，求平均值。
展望：1）
通過協議分析工具與負載測試工具結合自動獲取非同步傳輸過程中的響應時間，希望測試工具開發廠商可以思考一下這個問題，因為現在隨著
rcp技術的發展非同步傳輸的系統越來越多，那麼此類技術的測量點也會越來越多，希望工具廠商能夠重視。
2）協議分析工具自動分析，通過對開源的
ethereal
進行二次開發，初步完成這些功能：包括標誌位的設定，相關標誌位資料報文的抽取、響應時間的計算等功能。
期待…….
響應時間優化
業務不停的迭代，加上打工人換了一波又一波，導致很多業務介面特別重，可讀性非常的差。最近專案在重構優化，部分介面平均響應時間在 1.5s 左右，對於使用者體驗來說，非常的不友好。本文旨在提出幾個介面優化的一些常用的辦法。1 優化的準則 一切的前提是業務價值需要。如果沒有足夠的價值，那麼可讀性才是第一，...
Eureka響應時間優化
1 心跳傳送時間間隔 eureka.client.leaserenewalintervalinseconds 2 心跳檢查間隔 eureka.server.evictionintervaltimerinms 3 readwrite 快取 同步到 readonly 快取中的 間隔時間 eureka.s...
http響應時長分析
time namelookup dns 解析網域名稱www.bnxb.com的時間 time commect client和server端建立tcp 連線的時間 time starttransfer 從client發出請求 到web的server 響應第乙個位元組的時間 time total cli...