IIS伺服器的效能關係的我們的工作效率，因此不能有事阻礙到了IIS伺服器效能，不過很多人還是會犯一些錯誤導致IIS的效能受損，現在就來盤點一下哪些事情是千萬不能做的。
1、應該分配和釋放多個物件
你應該儘量避免過量分配記憶體，因為記憶體分配可能是代價高昂的。釋放記憶體塊可能更昂貴，因為大多數分配算符總是企圖連線臨近的已釋放的記憶體塊成為更大的塊。直到Windows NT? 4.0 service pack 4.0，在多執行緒處理中，系統堆通常都執行得很糟。堆被一個全域性鎖保護，並且在多處理器系統上是不可擴充套件的。
2.不應該考慮使用處理器快取記憶體
大多數人都知道由虛擬記憶體子系統導致的hard 頁錯誤代價很高，最好避免。但是許多人認為其他記憶體訪問方法沒有什麼區別。自從80486以後，這一觀點就不對了。現代的CPUs比RAM要快得多，RAM至少需要兩級記憶體快取 ，高速L1 快取能儲存8KB資料和8KB指令，而較慢的L2 快取能儲存幾百KB的資料和程式碼，這些資料和程式碼混合在一起。L1 快取中記憶體區域的一個引用需要一個時鐘週期，L2 快取的引用需要4到7個時鐘週期，而主記憶體的引用需要許多個處理器時鐘週期。後一數字不久將會超過100個時鐘週期。在許多方面，快取像一個小型的，高速的，虛擬記憶體系統。
至於和快取有關的基本記憶體單元不是位元組而是快取列。Pentium 快取列有32個位元組寬。Alpha 快取列有64個位元組寬。這意味著在L1 快取中只有512個slot給程式碼和資料。如果多個數據一起使用(時間位置)而並不儲存在一起(空間位置)，效能會很差。陣列的空間位置很好，而相互連線的列表和其他基於指標的資料結構的位置往往很差。
把資料打包到同一個快取列中通常會有利於提高效能，但是它也會破壞多處理器系統的效能。記憶體子系統很難協調處理器間的快取。如果一個被所有處理器使用的只讀資料，和一個由一個處理器使用並頻繁更新的資料共享一個快取 列，那麼快取將會花費很長時間更新這個快取列的拷貝。這個Ping-Pong高速遊戲通常被稱為"快取 sloshing"。如果只讀資料在一個不同的快取 列中，就可以避免sloshing。
對程式碼進行空間優化比進行速度優化效率更高。程式碼越少，程式碼所佔的頁也越少，這樣需要的執行設定和產生的頁錯誤也會更少，同時佔據的快取 列也會更少。然而，某些核心函式應該進行速度優化。可以利用profiler去識別這些函式。
3.決不要快取頻繁使用的資料。
軟體快取可以被各種應用程式使用。當一個計算代價很高時，你會儲存結果的一個拷貝。這是一個典型的時空折中方法：犧牲一些儲存空間以節省時間。如果做得好，這種方法可能非常有效。
你必須正確地進行快取。如果快取了錯誤資料，就會浪費儲存空間。如果快取得太多，其他操作可以使用的記憶體將會很少。如果快取得太少，效率又會很低，因為你必須重新計算被快取 遺漏的資料。如果將時間敏感資料快取得時間過長，這些資料將會過時。一般，伺服器更關心的是速度而不是空間，所以他們要比桌面系統進行更多的快取。一定要定期去除不用的快取，否則將會有執行設定問題。
4.應該建立多個執行緒，越多越好。
調整伺服器中起作用的執行緒數目是很重要的。如果執行緒是I/O-bound的，將會花費很多時間用來等待I/O的完成-一個被阻塞的執行緒就是一個不做任何有用工作的執行緒。加入額外的執行緒可以增加通量，但是加入過多的執行緒將會降低伺服器的效能，因為上下文交換將會成為一個重大的overhead。上下文交換速度應該低的原因有三個：上下文交換是單純的overhead，對應用程式的工作沒有任何益處;上下文交換用盡了寶貴的時鐘週期;最糟的是，上下文交換將處理器的快取填滿了沒用的資料，替換這些資料是代價高昂的。
有很多事情是依靠你的執行緒化結構的。每個客戶端一個執行緒是絕對不合適的。因為對於大量使用者端，它的擴充套件性不好。上下文交換變得難以忍受，Windows NT用盡了資源。執行緒池模型會工作得更好，在這種方法中一個工人執行緒池將處理一條請求列，因為Windows 2000提供了相應的APIs，如QueueUserWorkItem。
原作者： 佚名