2. 客戶端每次讀的數據大小，也會影響到性能。在上面的例子中客戶端每次讀64KB，是一個比較好的數值。如果讀的值特別小(比如4KB)，會增加讀操作和往 返次數，從而影響性能。這個值的大小是由客戶端和服務器協商決定的?？蛻舳松贤耆Q于應用程序，服務器上一般有設置選項。比如Windows服務器提供 了SizReqBuf這個注冊表鍵值供用戶設置。
3. 另外一個性能影響因素是服務器的響應時間。對于讀操作，最常用的優化方式是啟用“prefetch”。即服務器在回復了前一個讀請求后，立即把接下來的數據從硬盤中讀出，等著回復下一個請求。
CIFS的寫操作和讀操作方式相似，對于相同點就不再贅述。不同點主要體現在響應時間的優化方式上。服務器為了優化寫操作的響應時間，一般采用 write cache的方式。也就是服務器先把客戶端寫過來的數據存在cache里，然后向客戶端確認。接下來再慢慢把cache里的數據刷進磁盤。當然這種方式存在一定的風險，如果服務器突然斷電，cache里的數據就會丟失?？蛻舳说膽贸绦蚩梢詥⒂脀rite throuth來避免write cache。
下面，我們再看看NFS的工作方式。
和CIFS不同，NFS共享在使用前需要掛載(mount)。掛載時使用的參數很大程度上影響了讀寫的性能。列舉如下：
1. UDP或TCP：在網絡非常穩定的情況下，UDP理論上比TCP性能好一點，因為UDP包在協議上的消費比例低。但是如果有網絡包丟失，TCP就顯示出優勢。因為UDP包丟失時，整個讀/寫操作的所有包都要重傳;而TCP包丟失時，只需重傳丟失的那個包即可。
2. rsize和wsize，每次讀寫的最大值。該值對性能的影響和CIFS的第二點是一樣的，所以不再贅述。
3. sync和async，sync意味著服務器需要把數據寫到磁盤再確認;async則意味著服務器可以把數據存到cache里就確認，然后再慢慢把 cache里的數據刷進磁盤。有一個經常被忽視的嚴重問題：sync參數會強制wsize變成4KB，這會大大降低寫性能。
本文介紹的幾種優化方式，比如啟用SMB2，增加rsize等，除了它們本身能優化性能，還能提高傳輸層的性能，我們將在下一篇博文中詳細介紹這一點。
