1- 不要為每個小數(shù)據(jù)包發(fā)送一個IOCP請求,這樣很容易耗盡IOCP的內(nèi)部隊(duì)列.....從而產(chǎn)生10055錯誤.
2- 不要試圖在發(fā)送出IOCP請求之后,收到完成通知之前修改請求中使用的數(shù)據(jù)緩沖的內(nèi)容,因?yàn)樵谶@段時間,系統(tǒng)可能會來讀取這些緩沖.
3- 為了避免內(nèi)存拷貝,可以嘗試關(guān)閉SOCKET的發(fā)送和接收緩沖區(qū),不過代價是,你需要更多的接收請求POST到一個數(shù)據(jù)流量比較大的SOCKET,從而保證系統(tǒng)一直可以找到BUFFER來收取到來的數(shù)據(jù).
4- 在發(fā)出多個接收請求的時候,如果你的WORKTHREAD不止一個,一定要使用一些手段來保證接收完成的數(shù)據(jù)按照發(fā)送接收請求的順序處理,否則,你會遇到數(shù)據(jù)包用混亂的順序排列在你的處理隊(duì)列里.....
5- 說起工作線程, 最好要根據(jù)MS的建議, 開 CPU個數(shù)*2+2 個, 如果你不了解IOCP的工作原理的話.
6- IOCP的工作線程是系統(tǒng)優(yōu)化和調(diào)度的, 自己就不需要進(jìn)行額外的工作了.如果您自信您的智慧和經(jīng)驗(yàn)超過MS的工程師, 那你還需要IOCP么....
<new update @ 2008-3-7 1:00>
7-發(fā)出一個Send請求之后，就不需要再去檢測是否發(fā)送完整，因?yàn)閕ocp會幫你做這件事情，有些人說iocp沒有做這件事情，這和iocp的高效能是相悖的，并且我做過的無數(shù)次測試表明，Iocp要么斷開連接，要么就幫你把每個發(fā)送請求都發(fā)送完整。
8- 出現(xiàn)數(shù)據(jù)錯亂的時候，不要慌，要從多線程的角度檢查你的解析和發(fā)送數(shù)據(jù)包的代碼，看看是不是有順序上的問題。
9- 當(dāng)遇到奇怪的內(nèi)存問題時，逐漸的減少工作線程的數(shù)量，可以幫你更快的鎖定問題發(fā)生的潛在位置。
10-同樣是遇到內(nèi)存問題時，請先去檢查你的客戶端在服務(wù)器端內(nèi)部映射對象的釋放是否有問題。而且要小心的編寫iocp完成失敗的處理代碼，防止引用一個錯誤的內(nèi)部映射對象的地址。
11- overlapped對象一定要保存在持久的位置，并且不到操作完成（不管成功還是失敗）不要釋放，否則可能會引發(fā)各種奇怪的問題。
12- IOCP的所有工作都是在獲取完成狀態(tài)的那個函數(shù)內(nèi)部進(jìn)行調(diào)度和完成的，所以除了注意工作線程的數(shù)量之外，還要注意，盡量保持足夠多的工作線程處在獲取完成狀態(tài)的那個等待里面，這樣做就需要減少工作線程的負(fù)擔(dān)，確保工作線程內(nèi)部要處理費(fèi)時的工作。（我的建議是工作線程和邏輯線程徹底區(qū)分開）
13- 剛剛想起來，overlapped對象要為每次的send和recv操作都準(zhǔn)備一個全新的，不能圖方便重復(fù)利用。
14- 盡量保持send和recv的緩沖的大小是系統(tǒng)頁面大小的倍數(shù)，因?yàn)橄到y(tǒng)發(fā)送或者接收數(shù)據(jù)的時候，會鎖用戶內(nèi)存的，比頁面小的緩沖會浪費(fèi)掉整個一個頁面。（作為第一條的補(bǔ)充，建議把小包合并成大包發(fā)送）
<未完待續(xù)>