效能需求：使用者和系統管理員
使用者透過其體驗來判斷應用程式效能：
- 應用程式是否快速回應？
- 執行背景作業時是否顯示沙漏圖示？
- 應用程式是否快速啟動並關閉？
- 錯誤是否以可理解的方式處理？
總而言之，使用者希望應用程式快速且可預測。
相反地，系統管理員通常會判斷應用程式使用網路資源的效率。 系統管理員可能會詢問：
- 應用程式是否有低額外負荷且有效率的網路使用量？
- 使用的連線數目下限，因此我的伺服器可以一次服務多個使用者嗎？
- 我是否持續撥打技術服務人員？
簡言之，系統管理員希望應用程式進行調整。
效能需求的最佳做法
開發 Windows Sockets 應用程式時，這些效能需求會轉譯為有用的規則。
讓網路應用程式快速初始化。
使用者介面不應該等候網路回應。 某些工作可以在網路可用或沒有網路之前執行。 如果網路沒有回應，使用者可能需要使用者介面來進行簡單的作業，例如關閉應用程式。
請勿等候網路關閉。
正確撰寫的用戶端應用程式會正常處理中止的中斷連線。 請勿起始可能冗長的作業，例如將檔案或資料夾與伺服器同步處理，無法在關機時中斷。 網路不一致地回應，因此即使是小型作業也可能會證明耗時。 為使用者提供正面的意見反應，包括進度和估計完成時間的指示。
確定回應式使用者介面。
應用程式回應性有助於消除不必要的技術服務人員呼叫。 互動式回應的良好指導方針為 500 毫秒。 使用者認為暫停時間超過 500 毫秒，因為效能延遲。 應用程式應該有足夠的回應能力，讓使用者確信應用程式。
仔細檢查網路錯誤。
並非所有網路錯誤都很重要。 例如，已接收或張貼其所有資料的應用程式可能會忽略關閉連線時的錯誤。 請勿假設網路或使用者可供使用;處理錯誤而不需使用者介入，或在錯誤為非關鍵時予以忽略。
應用程式應該定義自己的合理逾時。
例如，Windows Sockets connect () 要求可能會在某些條件下封鎖多達 21 秒。 應用程式可能需要為使用者適當地引進自己的逾時。
將通訊協定額外負荷降到最低。
節省網路頻寬是關於將應用程式所產生的通訊協定額外負荷降到最低。 它也與消除不必要的網路流量有關。 具有較低標頭額外負荷的通訊協定可用來傳輸應用程式資料。 例如，當傳送較少的非關鍵或可重復資料時，請使用 UDP 而非 TCP，以減少與連線建立和維護相關聯的額外負荷。 如果必須傳送相同的資料給多個收件者，請考慮多播。 請注意，UDP 應用程式不會受到流量控制-- 推送超出可用頻寬可能會導致重大網路失敗。 Netstat 公用程式可以搭配其 -e 和 -s 選項使用，以顯示各種通訊協定的統計資料。
節省系統資源。
如果未使用適當的調和，系統資源可以快速取用。 例如，通訊端和 TCP 連線會耗用資源。 請勿針對每個用戶端使用數個 TCP 連線，其中一個會提供應用程式的用途。
對於交易式應用程式，良好的使用者體驗和低網路使用率並非衝突的目標。 網路是瓶頸。 需要大量網路的應用程式會花更多時間等候，而撰寫良好的網路應用程式的設計目的是為了將使用者介面和網路傳輸的不必要的等候時間降到最低。
相關主題