新的一年又要開始，深思了自己一年的工作，總結了一些問題，與大家交流
第一、程序編寫過程中非優化語句
編寫高性能代碼有很多要注意的東西，因為我關注的是數據庫方面的，所以會從SQL語句方面的優化來說一下，程序員在編寫代碼的時候因為水平不同，并且沒有考慮數據庫中數據量的問題，編寫的代碼在功能測試時是沒問題，但當進行穩定性測試的時候，數據庫中有很多測試數據的情況下，系統的性能下降就很明顯了。比如一個新聞表中，有ID,NEWS,DATE,CLASSE,AUTHOR這樣幾個字段，ID是主鍵，每天大概有2000條的增量，每年有72萬條的增量，這樣一條語句 select * from table where class ='1'，可以看到就是
建立了索引，該表還是進行全表掃描，當運行一年后，系統的速度大家就可以相象了。
還有一些需要用存儲過程的，也是在程序中編輯SQL語句，該使用綁定變量的也沒有使用綁定變量，等等問題。
第二、結構設計不合理造成的性能問題
我發現這類問題是造成性能問題最多的，也是性能調優的重點，通過對結構的調整，性能變化也最明顯。結構設計包括程序結構設計和數據結構設計，這兩部分一定要綜合考慮，但我發現大多數的軟件對程序結構設計偏重的多，對數據結構設計考慮的不是太充分，在下面的例子中我會說明。
例子一：GIS在線編輯圖形
在ARCGIS SERVER 9中提供了通過WEB程序來編輯圖形的功能，但它的工作機制是，只要客戶端啟動了編輯功能，后臺ARCGIS SERVER就要啟動一個進程(類似與啟動了一個ARCMAP)，所以對后臺的性能壓力是非常大的，特別是CPU。如果程序在結構設計的時候沒有考慮這些問題，當較多的用戶進行圖形編輯的時候，系統就會崩潰。事實也確實是這樣，當進行性能壓力測試的時候，在5個用戶壓力下，WEB服務器、數據庫服務器的壓力都非常小，而ARCGIS SERVER已經幾乎不能運行了。這部分的設計應該借鑒中間件的思路，簡歷一個一直運行的進程，設立一個最大數，當用戶有圖形編輯的要求時，就把請求發到進程池中，如果有空閑的進程就直接利用空閑的進程，否則就等待。
例子二：大文件的上傳
在一個《企業信息門戶》中，允許用戶上傳一些資料，在數據庫設計中，這些資料是保存在一個表中的BLOB字段中，并且有一個編號ID做主鍵，這樣在用戶量比較小的時候是沒有問題的，當用戶數比較大時，并且并發比較大時，對ORACLE的內存占用很大，并且因為有索引，插入時還要更新索引，開銷更大，如果把文件保存到硬盤上而不是保存到數據庫中，隨說磁盤的IO速度較慢，但因為是網絡的文件傳輸，網速有限制，這樣比存到數據庫中的性能要提高很大。
例子三：大數據表問題
在一個關于“測井曲線”成圖的系統中，因為是把各個點生成曲線，數據量非常大，這樣造成一個表非常大，在進行數據結構設計時，對該表的容量沒有充分考慮，造成程序運行一段時間后非常慢，把大數據表進行分區后，效果非常明顯。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
