引言 前提
項目組裡無用到SPRING進行事務的管理
項目裡以功能劃分到每個人手裡
形成了BO
DAO
ACTION
VIEW都是單人負責
在DAO中每個動作都以
封閉式的形式存在
問題
造成事務的不連貫性
功能是做出來了
性能問題遲早暴露
測試
主要針對程序頻繁請求數據庫連接對WEB應用所造成影響做一個測試
先做必要的說明
一步步引入正題
先從性能瓶頸開始
性能瓶頸 所有的應用程序都存在性能瓶頸
為了提高應用程序的性能
就要盡可能的減少程序的瓶頸
以下是在JAVA程序中經常存在的性能瓶頸
了解了這些瓶頸後
就可以有針對性的減少這些瓶頸
從而提高JAVA應用程序的性能
數據庫連接池工作原理 關於連接池的實現原理測試方案
經過資料的收集與APACHE DBCP裡連接池的查閱
對現有的連接池工作原理有兩種方式
數據庫預先設置配置好的連接數
待得到用戶請求連接
傳出一個連接
而後為了保持供應數再提前創建連接
即提前預備連接數供請求
比如
有
個通行道代表最大激活的連接數
最小
個閒置連接數
也就是說連接池裡始終預備了
個可隨時提供的連接
連接的創建開銷是比較大的
連接池的存在就是了能夠最小化的解決創建所等待的時間
O
O
*
*
*
如上圖
當
分配出去時由於池中連接數剩一個
為保持最小閒置
會自動創建一個新的連接以防止再次請求等待創建的時間
這樣確實減少了等待的時間
但是數據庫創建的開銷方面並未得到解決
如果把
比喻成汽車
那麼這種情況下每量車都是一次性使用
被請求後下一個連接將是
來接替
那麼如何能夠重復利用
減少數據庫開銷
於是引出第二種方式
回收使用完後的連接
放回到池中進行循環利用
這麼做必須能保證
點
一
使連接能夠保持有效的回收
二
約束使用者使用釋放的動作
而不是直接把連接close
筆者使用的是APACHE DBCP裡BasicDataSource的連接池基本實現
經過代碼與測試結果顯示
其工作方式是基於二的
BasicDataSource測試用例
下面展示了一個測試用例
測試結果
第
組數據:
並發應用數
模擬連接數
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
第
組數據共執行
次;平均耗時為
毫秒
平均使用
個連接
第
組數據:
並發應用數
模擬連接數
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
第
組數據共執行
次;平均耗時為
毫秒
平均使用
個連接
第
組數據:
並發應用數
模擬連接數
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
運行平均耗時
共使用
個連接
第
組數據共執行
次;平均耗時為
毫秒
平均使用
個連接
每次測試的結果都可能不同
但是所得到的結論是一致的
數據顯示不合理的請求使用連接嚴重的影響應用所能承受的並發數量
響應的時間也因此受到影響
目前普遍存在的問題 沒有把事務控制好
一般會出現以下的情況
事務(){ 流程
(); 流程
();}
可以看出流程
裡都是單獨創建連接
並在自己的流程裡完成操作
如果在流程
裡出現異常
那麼流程
所做的操作是不可恢復的
如果能控制在事務范圍內
如
事務(){ Connection con; 流程
(con); 流程
(con); con
close();}
那麼數據庫少提供一個連接
事務的完成性也得到體現
在並發數量大的時候
效率上就有非常明顯的區別
解決方案 盡量保持少的請求
如DAO中有update()方法
則應再擴展一個方法update(Connection conn)
在業務邏輯事務裡調用update(Connection conn)
一般情況下調用update()
對於數據不變的情況采用緩存技術
或部分緩存技術
可參照一些相關的開源的項目（JIVE）
From:http://tw.wingwit.com/Article/program/Java/hx/201311/27107.html
