查看 sql server 連接數(shù)的指令為：sp_who 、 sp_who active 、sp_who2 和 sp_who2 active ，至于其中的區(qū)別，請大家search一下，這里不再解釋了


由于公司最近兩個Web站點做了負(fù)載均衡，但是緩存機制仍然是 Asp.Net 自帶的緩存，這樣就導(dǎo)致了每臺Web 服務(wù)器內(nèi)存中都有一份緩存，直接導(dǎo)致了多次請求DB數(shù)據(jù)庫，造成了DB連接數(shù)過高。

由于是兩個較大的站點兩臺服務(wù)器做負(fù)載均衡（負(fù)載平衡），所以，DB 的連接數(shù)也飆升，幾乎翻了3倍。


公司DB服務(wù)器用的是 Sql Server 2008 R2 ，并且DB服務(wù)器配置是相當(dāng)?shù)膹姾返�，連接數(shù)一度沖擊到740，真是讓人驚嘆不已。雖然鏈接數(shù)強悍，但是前臺訪問的頁面 超時的 也是茫茫多，沒辦法，只能采用了緊急處理：
1. 加大程序中的緩存，特別是頁面頭部加上 OutPutCache 緩存。
2. 用上鏡像的備份DB服務(wù)器，把2個站點的DB鏈接改到了鏡像的DB，這臺鏡像DB和現(xiàn)在主DB是不在同一個機房的，目標(biāo)就是容災(zāi)和在高流量的情況下快速切換

雖然緊急處理了，鏈接數(shù)降低了下來，但是通過這次發(fā)現(xiàn)，Sql Server 2008 R2  的連接數(shù)還是很容易造成性能瓶頸的，瓶頸也就是400左右，超過400，就會造成部分超時等待，但是少于400，就會比較順暢。當(dāng)然，這個是和服務(wù)器配置有關(guān)的。

最根本的解決辦法，只能是把 MemberCache 給用上了，哎。