我的WCF最初是託管在win7的IIS下。由於client OS （win7等）中IIS的最大連接數爲10，即WCF的併發上限被IIS限制在10。迫於IIS的限制，現在考慮將WCF轉移到win7的Windows Services下。
爲了對比WCF託管在IIS、Windows Services下的性能，做了如下實驗。
1.測試環境
win7虛擬機(企業版 雙核 64位) 、 2008r2虛擬機（Datacenter 雙核 64位）
2.測試方案
方案A：WCF託管在IIS（win7）下
方案B：WCF託管在Windows Services（win7）下
方案C：WCF託管在IIS（2008r2）下
方案D：WCF託管在Windows Services（2008r2）下
3.測試方法
用java編寫的程序，向WCF發送指定個數的http請求，以下測試均調用的是WCF的GetInfo()接口。該接口處理一個請求的時間約70毫秒。該接口的實例上限爲100。
測試分爲幾個時間點：初始化、第一個請求、第一波、第二波、第三波、N波後。
初始化：WCF初始化(IIS下的WCF服務接收到第一個請求才會真正初始化)。
第一個請求：WCF初始化後處理的第一個請求。
第一、二、三波：WCF初始化後，向WCF發送第一波請求（1000個），待第一波請求處理完，過15s，向WCF發送第二波請求，以此類推。
4.測試結果
四種方案處理1000個請求的時間及Cpu峯值
四種方案處理1000個請求所需的時間約10s。
對比方案B和方案D，可以看出win7+Services可以達到08r2+Services的響應速度。
對比方案A和方案B、方案C和方案D，得出Windows Services下的WCF的Cpu峯值稍低於IIS下WCF的。
四種方案的WCF在不同時間點的內存佔用情況
注意上圖下方是兩條線（方案B 和方案D）。
對比方案A和方案B、方案C和方案D，得出Windows Services下的WCF所佔的內存佔用明顯低於IIS下WCF的。
對比方案A和方案C，可以看出，從第二波開始，win7下的IIS託管的WCF的內存佔用明顯低於08r2下的。由於win7下的IIS限制了WCF的併發爲10，而08r2下IIS並沒有限制，導致08r2 IIS託管的WCF起的線程比較多，而這些線程結束後，並沒有及時釋放內存資源。
通過對比可以看出，win7+IIS或win7+Windows Services託管WCF可以達到08r+IIS託管WCF的響應速度。而win7+Windows Services的內存佔用明顯低於win7+IIS。目前看來win7+Windows Services既可以省08r2的license又可以省內存佔用。
儘管win7+IIS有IIS最大連接數10的限制，但GetInfo()接口的響應速度是毫秒級的，因此win7+IIS還是可以在短時間內處理1000個請求了。爲了進一步測試，我讓GetInfo()接口在接到請求後，先睡5秒，之後再繼續執行操作。
測試結果如下
四種方案處理1000個請求所需時間及Cpu峯值
方案B、C、D處理1000個請求所需的時間約76s。這次可以清晰的看出win7+IIS的問題，由於win7下IIS最大連接數10的限制，即可以理解10個請求爲一組，這一組響應時間爲5秒，這一組請求處理完了再處理下一組，可以算出1000/10=100組，100*5=500秒，跟實驗數據接近。
對比方案A和方案C的Cpu峯值，可以看出08r2+IIS的Cpu峯值高於win7+IIS，原因在於08r2+IIS的併發能力遠遠高於win7+IIS。
對比方案B和方案D，可以看出win7+Services可以達到08r2+Services的響應速度。
通過對比之前的測試結果可以看出，這次測試的Cpu峯值明顯低於上一次，我感覺是這次測試並沒有那麼頻繁的建立連接、斷開連接。
四種方案的WCF在不同時間點的內存佔用情況
注意上圖下方是兩條線（方案B 和方案D）。
四種方案的曲線跟第一次測試類似。
目前看來方案B，即WCF託管在win7 Windows Services下是WCF的最優方案！