1- 不要為每個小資料包傳送一個IOCP請求,這樣很容易耗盡IOCP的內部佇列.....從而產生10055錯誤.

2- 不要試圖在傳送出IOCP請求之後,收到完成通知之前修改請求中使用的資料緩衝的內容,因為在這段時間,系統可能會來讀取這些緩衝.
 
3- 為了避免記憶體拷貝,可以嘗試關閉SOCKET的傳送和接收緩衝區,不過代價是,你需要更多的接收請求POST到一個數據流量比較大的SOCKET,從而保證系統一直可以找到BUFFER來收取到來的資料.

4- 在發出多個接收請求的時候,如果你的WORKTHREAD不止一個,一定要使用一些手段來保證接收完成的資料按照發送接收請求的順序處理,否則,你會遇到資料包用混亂的順序排列在你的處理佇列裡.....

5- 說起工作執行緒, 最好要根據MS的建議, 開 CPU個數*2+2 個, 如果你不瞭解IOCP的工作原理的話.

6- IOCP的工作執行緒是系統優化和排程的, 自己就不需要進行額外的工作了.如果您自信您的智慧和經驗超過MS的工程師, 那你還需要IOCP麼....

<new update @ 2008-3-7 1:00>
7-發出一個Send請求之後，就不需要再去檢測是否傳送完整，因為iocp會幫你做這件事情，有些人說iocp沒有做這件事情，這和iocp的高效能是相悖的，並且我做過的無數次測試表明，Iocp要麼斷開連線，要麼就幫你把每個傳送請求都發送完整。

8- 出現數據錯亂的時候，不要慌，要從多執行緒的角度檢查你的解析和傳送資料包的程式碼，看看是不是有順序上的問題。

9- 當遇到奇怪的記憶體問題時，逐漸的減少工作執行緒的數量，可以幫你更快的鎖定問題發生的潛在位置。

10-同樣是遇到記憶體問題時，請先去檢查你的客戶端在伺服器端內部對映物件的釋放是否有問題。而且要小心的編寫iocp完成失敗的處理程式碼，防止引用一個錯誤的內部對映物件的地址。

11- overlapped物件一定要儲存在持久的位置，並且不到操作完成（不管成功還是失敗）不要釋放，否則可能會引發各種奇怪的問題。

12- IOCP的所有工作都是在獲取完成狀態的那個函式內部進行排程和完成的，所以除了注意工作執行緒的數量之外，還要注意，儘量保持足夠多的工作執行緒處在獲取完成狀態的那個等待裡面，這樣做就需要減少工作執行緒的負擔，確保工作執行緒內部要處理費時的工作。（我的建議是工作執行緒和邏輯執行緒徹底區分開）

13- 剛剛想起來，overlapped物件要為每次的send和recv操作都準備一個全新的，不能圖方便重複利用。

14- 儘量保持send和recv的緩衝的大小是系統頁面大小的倍數，因為系統傳送或者接收資料的時候，會鎖使用者記憶體的，比頁面小的緩衝會浪費掉整個一個頁面。（作為第一條的補充，建議把小包合併成大包傳送）

<未完待續>