<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆-23  評論-6  文章-1  trackbacks-0

             影響性能的測試報告(數(shù)據(jù)庫版)

    引言

    如需轉(zhuǎn)載,請與筆者聯(lián)系

     

    前提:項目組里無用到SPRING進行事務(wù)的管理。項目里以功能劃分到每個人手里,

    形成了BODAOACTIONVIEW都是單人負責。在DAO中每個動作都以

          封閉式的形式存在。

    問題:造成事務(wù)的不連貫性。功能是做出來了,性能問題遲早暴露。

    測試:主要針對程序頻繁請求數(shù)據(jù)庫連接對WEB應(yīng)用所造成影響做一個測試。

     

     

    先做必要的說明,一步步引入正題,先從性能瓶頸開始:

    性能瓶頸

    所有的應(yīng)用程序都存在性能瓶頸,為了提高應(yīng)用程序的性能,就要盡可能的減少程序的瓶頸。以下是在JAVA程序中經(jīng)常存在的性能瓶頸。

    pingjing.jpg
    了解了這些瓶頸后,就可以有針對性的減少這些瓶頸,從而提高JAVA應(yīng)用程序的性能

     

    數(shù)據(jù)庫連接池工作原理

    關(guān)于連接池的實現(xiàn)原理測試方案:

    經(jīng)過資料的收集與APACHE DBCP里連接池的查閱,對現(xiàn)有的連接池工作

    原理有兩種方式:

    1.        數(shù)據(jù)庫預(yù)先設(shè)置配置好的連接數(shù)。待得到用戶請求連接,傳出一個連接,而后為了保持供應(yīng)數(shù)再提前創(chuàng)建連接,即提前預(yù)備連接數(shù)供請求。比如:

    5個通行道代表最大激活的連接數(shù),最小2個閑置連接數(shù)。也就是說連接池里始終預(yù)備了2個可隨時提供的連接,連接的創(chuàng)建開銷是比較大的,連接池的存在就是了能夠最小化的解決創(chuàng)建所等待的時間。

      1            O

      2            O

      3            *

      4            *

      5            *

      如上圖,當1分配出去時由于池中連接數(shù)剩一個,為保持最小閑置,會自動創(chuàng)建一個新的連接以防止再次請求等待創(chuàng)建的時間。這樣確實減少了等待的時間,但是數(shù)據(jù)庫創(chuàng)建的開銷方面并未得到解決。如果把1-5比喻成汽車,那么這種情況下每量車都是一次性使用。1被請求后下一個連接將是6來接替。那么如何能夠重復(fù)利用1減少數(shù)據(jù)庫開銷。于是引出第二種方式。

     

    2.        回收使用完后的連接,放回到池中進行循環(huán)利用。這么做必須能保證2

       .  使連接能夠保持有效的回收。

       .  約束使用者使用釋放的動作,而不是直接把連接close.

     

    本人使用的是APACHE DBCPBasicDataSource的連接池基本實現(xiàn),

    經(jīng)過代碼與測試結(jié)果顯示,其工作方式是基于二的。

     

    BasicDataSource測試用例

    請看測試用例

    測試結(jié)果:


    2組數(shù)據(jù):

    并發(fā)應(yīng)用數(shù):100 模擬連接數(shù):6

    運行平均耗時:2956

    共使用51個連接

    運行平均耗時:3391

    2共使用52個連接

    運行平均耗時:2616

    共使用47個連接

    運行平均耗時:3377

    共使用41個連接

    運行平均耗時:3673

    共使用46個連接

    2組數(shù)據(jù)共執(zhí)行5;平均耗時為:3229毫秒

    平均使用47個連接

     

    3組數(shù)據(jù):

    并發(fā)應(yīng)用數(shù):85 模擬連接數(shù):9

    運行平均耗時:4830

    共使用53個連接

    運行平均耗時:3247

    共使用49個連接

    運行平均耗時:4116

    共使用40個連接

    運行平均耗時:4070

    共使用43個連接

    運行平均耗時:4053

    共使用54個連接

    3組數(shù)據(jù)共執(zhí)行5;平均耗時為:4063毫秒

    平均使用47個連接

     

    4組數(shù)據(jù):

    并發(fā)應(yīng)用數(shù):140 模擬連接數(shù):3

    運行平均耗時:2076

    共使用47個連接

    運行平均耗時:3104

    共使用51個連接

    運行平均耗時:2048

    共使用43個連接

    運行平均耗時:2421

    共使用50個連接

    運行平均耗時:2751

    共使用50個連接

    4組數(shù)據(jù)共執(zhí)行5;平均耗時為:2480毫秒

    平均使用48個連接

     

    每次測試的結(jié)果都可能不同,但是所得到的結(jié)論是一致的。數(shù)據(jù)顯示不合理的請求使用連接嚴重的影響應(yīng)用所能承受的并發(fā)數(shù)量,響應(yīng)的時間也因此受到影響。

     

    目前普遍存在的問題

    沒有把事務(wù)控制好,一般會出現(xiàn)以下的情況:

    事務(wù)(){

      流程1();

      流程2();

    }

    可以看出流程12里都是單獨創(chuàng)建連接,并在自己的流程里完成操作。

    如果在流程2里出現(xiàn)異常,那么流程1所做的操作是不可恢復(fù)的。

    如果能控制在事務(wù)范圍內(nèi),如:

    事務(wù)(){

      Connection con;

      流程1(con);

      流程2(con);

      con.close();

    }

    那么數(shù)據(jù)庫少提供一個連接,事務(wù)的完成性也得到體現(xiàn)。在并發(fā)數(shù)量大的時候,

    效率上就有非常明顯的區(qū)別。

    解決方案

    1.  盡量保持少的請求

    DAO中有update()方法,則應(yīng)再擴展一個方法update(Connection conn)

    在業(yè)務(wù)邏輯事務(wù)里調(diào)用update(Connection conn),一般情況下調(diào)用update()

    2.  對于數(shù)據(jù)不變的情況采用緩存技術(shù),或部分緩存技術(shù)。

          可參照一些相關(guān)的開源的項目(JIVE)。

    posted on 2005-09-25 17:21 ceaboat 閱讀(1663) 評論(4)  編輯  收藏 所屬分類: JAVA小結(jié)

    評論:
    # re: 影響性能的測試報告(數(shù)據(jù)庫版) 2005-09-25 19:40 | martin xus

    討論一下:)

    一:
    事務(wù)(){
    流程1();
    流程2();
    }

    這樣的事務(wù)完全可以控制的,例如:采用command的模式

    Transactable tx = null;
    try{
    tx.begin();
    command = cmd.execute();
    tx.commit();
    } catch (Throwable e) {
    if (tx != null) {
    try {
    tx.rollback();
    } catch (Exception he) {
    throw new GeneralFailureException("事務(wù)回滾出錯", he);
    }
    }
    }

    這完全沒有問題的.


    二:
    個人認為connection沒有必要擴大到外面來,
    Connection con;
    流程1(con);
    流程2(con);
    con.close();
    connection應(yīng)該是透明的,不應(yīng)該出現(xiàn)在你的業(yè)務(wù)代碼中,再說,你的一個application不是有connection pool嗎?應(yīng)該把connection交給容器去管理.

    再者:
    如果出現(xiàn)以下任一種情況怎么辦或者被別人誤用:
    (1):你的connection 被聲明為static
    (2):代碼沒有執(zhí)行完畢,拋出異常,而又沒有合理處理connection
    那么這樣你的連接就可能被占著不放.做gc同樣也釋放不了.你的server肯定會菪機!


    你說呢?
      回復(fù)  更多評論
      
    # re: 影響性能的測試報告(數(shù)據(jù)庫版) 2005-09-25 20:24 | ceaboat
    我這里只做最普通的例子說明,并不是重在一定使用這種方式,重點是在于事務(wù)進行統(tǒng)一,雖然大家都知道這個,但是出呼意料,在項目中我看到更多的是使用
    事務(wù)(){
    流程1();
    流程2();
    }
    對于我來說難以理解,于是有必要做這個測試報告,在會議上進行討論。
    當然在正常使用中,異常的處理是必須的,但不是這個測試的重點所在。
    重點在于不合理的使用連接,頻繁的進行網(wǎng)絡(luò)交互所給系統(tǒng)帶來的負擔。  回復(fù)  更多評論
      
    # re: 影響性能的測試報告(數(shù)據(jù)庫版) 2005-09-25 20:32 | InPractice
    在同一個事務(wù)中,流程1和流程2共用一個連接應(yīng)該效率較高。實踐中大家可能都沒有注意這個。因為一般是DAO和SERVICE兩層。每個DAO是獨立的,組合到Service中時也沒有特意讓兩個DAO共享同一個連接,就會出現(xiàn)上面的情況。  回復(fù)  更多評論
      
    # re: 影響性能的測試報告(數(shù)據(jù)庫版) 2005-09-26 09:04 | martin xus
    在一個項目中,非不得以,事務(wù)不應(yīng)該交給組員去做的,對他們來說,這是不允許的.
    在他們的模塊中只是簡單的業(yè)務(wù)處理.普通的代碼,調(diào)用相應(yīng)的service..

    開發(fā)前,先給組員開 “項目規(guī)范動員大會” :)  回復(fù)  更多評論
      
    主站蜘蛛池模板: 国产在线精品观看免费观看| 国产精品无码亚洲一区二区三区| 免费国产作爱视频网站| 亚洲va无码专区国产乱码| 久香草视频在线观看免费| 毛片免费观看的视频在线| 亚洲av无码片区一区二区三区| 亚洲精品美女久久7777777 | 国产成人精品久久亚洲| 亚洲精品久久久久无码AV片软件| 国产成人无码免费网站| 国产日产亚洲系列| 最近免费中文字幕MV在线视频3| 日韩免费一区二区三区在线 | 亚洲另类激情专区小说图片| 国产精品久久久久久亚洲影视| a级片免费在线观看| 久久国产亚洲精品麻豆| 中文字幕成人免费高清在线视频 | 亚洲高清毛片一区二区| 国产成人免费片在线视频观看| 亚洲精品无码成人AAA片| 中文无码成人免费视频在线观看| 扒开双腿猛进入爽爽免费视频 | 亚洲人成人网站在线观看| 深夜福利在线视频免费| 亚洲色婷婷综合久久| 免费人成网站在线观看不卡| 亚洲精品白色在线发布| 四虎成人免费观看在线网址| 免费在线观看一区| 久久夜色精品国产嚕嚕亚洲av| 四虎精品成人免费视频| 亚洲精品无码久久久久去q| 4hu四虎最新免费地址| 亚洲欧美第一成人网站7777 | 2022国内精品免费福利视频| 亚洲AV日韩AV鸥美在线观看| 久久久久久精品成人免费图片| 国产亚洲精品a在线观看app | 久久精品a亚洲国产v高清不卡 |