安達利機車行

手邊負責的系統中，有一個需多人同時上線來做資料新刪修的系統
在尖峰時刻或許會多到一、兩千人同時上線...

撇開程式面不談，在開發過程中已簡化程式的複雜程度與邏輯運算，
還有盡量以不要常常POST BACK頁面回Server為原則，
但是在AP Server(IIS)與資料庫(SQL Server)之間的配合卻有更多需要考量的因素。

一開始當資料量還少時(五六萬筆以內)，系統跑來還算順暢
沒有什麼lag發生，所以user一般來說反應算是良好。

當資料量一直累積時(超過二十萬筆資料)，遭遇的問題也愈來愈多...
曾經在系統開放前以為做好萬全準備，
結果一上線之後整個資料庫系統busy到幾乎當機(CPU100%)

在此提供一些開發過程中的心得，與大家一同分享。

以提升效能的角度來看...
一般來說除了資料的新刪修外，「查詢」是每個系統另一項主要的工作
user在新刪修資料之前或多或少須透過查詢的動作來取得出他所要的內容。 

A.索引的建立...
這時index「索引」的建立就必需要好好的考量與規劃，
一兩萬筆資料的table或許不需要考慮index的建立，但是如果當資料量一大時，
index絕對有助於user快速地找到資料(當然index的建立所犧牲的代價就是硬碟空間)，
如果規劃得宜，可以把1秒的查詢縮短到0.1秒就可完成。

B.索引的規劃...
如刀刃兩面一般，帶來好處必然會有所損失，index的建立提升了查詢的效能
也因為index talble的建立，必然會影響到資料在新刪修時的效能。
以sql server為例，之前不小心把一個異動頻繁table的index填滿因素填太高(90%)，
而影響到資料在新刪修時的效能，尤其在多人同時上線資料異動頻繁時最為明顯，
因為資料異動量實在過於頻繁，table索引分頁本身的預存空間過小，一旦新刪修資料時馬上變得很慢
試著把資料異動頻繁table的index填滿因素改成55%之後，果真有改善新刪修的效率。

C.索引的重整....
建立完index，如果資料的異動很頻繁，而疏忽了index的重整，這樣反而讓整體的效能大打折扣
index table以B-Tree的方式來建立，讓這顆樹可以漂亮地延展絕對比一顆支離破碎的大樹來得好，
說白話一點的，常整理的房間一定比「被搶打到」的雜亂房間乾淨且而好找東西吧，
以我們系統為例，定期把系統的index重整，確保table的索引分頁index page破碎率不會太高
利用DBCC SHOWCONTIG指令來檢查index的破碎率之外
重新整理index table的好方法除了把index刪掉再重新建立之外 
DBCC INDEXDEFRAG與DBCC DBREINDEX 這兩個重整指令都很值得參考。
相關的資料請參照…Microsoft SQL Server 2000 索引重組的最佳實務(值得參考的文件)

再來就是AP Server的Loading分擔....
分散AP Sever的Loading對於多人同時上線的系統或許可以說是雪中送碳(因為效能本來就吃緊)
將所有的Loading分散在不同的AP Server間可以除了疏通線上大量的user之外，
也可以讓降低每部AP Server的工作負擔。
以我們系統而言，除了資料庫只有一台之外，另外有四到五台AP Server來分擔線上所有的工作
因為AP Server比較多，所以可以試著在程式開發時把多一點的邏輯的運算丟給AP Server來處理
而不是留給孤軍奮戰已經快累死的DB Server。

最後是資料庫的規劃....
正規化是一門學問，不過為了要提升效能
或許在資料量存取大的table上可以試著反正規化
不要切太多欄位在分散的table或是做過多的關聯(最好不要超過三層的關聯)，
相信在效能上也會有所提升。

記憶體的重要性...
線上多人存取的系統，主機的記憶體相對的吃重
能多加一點當然會有助於系統的運作，尤其是DB Server...

以上...