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