安達利機車行

小弟這幾個月的工作主要是為了要讓一個核心編釋完之後只有4百多K的程式上線
可是這個四百多K的核心程式(不包含網頁程式)，
需要在同一時間(一兩秒之內)要服務上千個user...

一開始我對於自已並不敢抱執很堅定的信心
一直很怕效能的問題，更怕系統跑到一半就Crash了…
隨著系統的上線，雖不敢說非常地順利，不過也達成了最終的目標。

在這一次的開發過程中，小弟提出開發過中的一些心得和大家分享

一、瞬間的大量需求
這個系統其實Busy的時段只有在固定的時間點(例如訂票系統之類的)
雖不是一直都Busy，但是在瞬間需要承受大量的Request和資料的交易。
為了克服User大量的Request，我們利用多台的App Server來服務使用者
類似Load Balance或是DNS的做法...
也就是說，我們放了多台的AP Server來Share大量User的Request。
當你有多台AP Server來當為你服務時，我們就要改變我們的策略，
因此我把大部份的程式Logic處理放到每一台AP Server上來Run...
而不是透過孤單且苦命的DB Server來處理。

問題來了…AP Server再多台也沒關係，但是DB Server只能有一台吧…
因為在小弟的所學範圍裏面只會用一台DB(考慮資料同步的問題)

二、資料的快取
因為DB Server只能有一台，因些我們一定盡量讓DB Server不要做多餘的存取
因此我把一些異動頻率不高，但是讀取機率很高的資料，事先Load到每一台的AP Sever中…
當AP Sever一開機時就從資料庫中讀資料並將這些資料Load到每一台AP Server的記憶體中
這些資料通常是非常重要且讀取機率相當高的資料(系統參數或系統基本資料之類的)
我的做法是採取Singlton的方法，將這些資料快取在AP Server的記憶體當中…
以後要資料時，不需再連回資料庫，直接在AP Sever的記憶體中取得。
如果一但需要更新，再去Reset這個Instance...

三、精簡傳送的資料
通常網頁Submit回Server時，有一些人會將整個網頁送回去
(就是

和

裏面所包起來的內容...)
記得只送回需要處理的資料即可，別將一些沒有用的資料也送回去…

四、善用Store Procedure
在DB Server端盡可能請將所有的SQL語都利用Store Procedure的方式來實作，
因為Store Procedure是Compiler過的SQL語法…效能好、速度快、好維護。
不需再重新編釋，也節省資料的傳送(別送一大串的SQL語法回DB Server去編釋)

五、建立良好的資料庫索引與反正規化
當資料量一大時，如果沒有建立良好的索引(別建太多、也別亂建)-->不是萬靈丹
對資料搜索的速度有非常大的影響(相對的，索引的建立會影響Insert和Update的效率)
當建完索引之後，記得最好每天要重整一下索引，讓系統的效能發揮到最高。
千萬別做太多的JOIN(JOIN絕對不是我們的好朋友)，最好別超過四個JOIN...
如果需要很多的JOIN，為了效能好，請『反正規化』吧…

五、善用手邊的壓測工具
這次所幸後來和小弟的學長利用壓測工具找出了一些效能上的瓶頸
雖然我還是搞不太清楚如何利用『壓測工具』來調校出最佳的性能
不過這是個值得再好好研究的領域。

這是小弟這次在開發和實際上線時所遇到的一些問題和解決之道，
希望對大家有實質上的幫助，野人曝現，請大家多指教…