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

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

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

    posts - 122,  comments - 25,  trackbacks - 0
    (來源測試時代,http://www.testage.net)

    多數人對怎樣去分析工具收集到的測試結果感到無從下手,下面我就把個人工作中的體會和收集到的有關資料整理出來,希望能對大家分析測試結果有所幫助。

    分析原則:
        • 具體問題具體分析(這是由于不同的應用系統,不同的測試目的,不同的性能關注點)
        • 查找瓶頸時按以下順序,由易到難。
        服務器硬件瓶頸-〉網絡瓶頸(對局域網,可以不考慮)-〉服務器操作系統瓶頸(參數配置)-〉中間件瓶頸(參數配置,數據庫,web服務器等)-〉應用瓶頸(SQL語句、數據庫設計、業務邏輯、算法等)
        注:以上過程并不是每個分析中都需要的,要根據測試目的和要求來確定分析的深度。對一些要求低的,我們分析到應用系統在將來大的負載壓力(并發用戶數、數據量)下,系統的硬件瓶頸在哪兒就夠了。
        • 分段排除法 很有效

    分析的信息來源:
        •1 根據場景運行過程中的錯誤提示信息
        •2 根據測試結果收集到的監控指標數據

    一.錯誤提示分析

    分析實例:
    1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
      •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

      分析:
    •A、應用服務死掉。
       (小用戶時:程序上的問題。程序上處理數據庫的問題)
    •B、應用服務沒有死
       (應用服務參數設置問題)
        例:在許多客戶端連接Weblogic應用服務器被拒絕,而在服務器端沒有錯誤顯示,則有可能是Weblogic中的server元素的 AcceptBacklog屬性值設得過低。如果連接時收到connection refused消息,說明應提高該值,每次增加25%
    •C、數據庫的連接
       (1、在應用服務的性能參數可能太小了 2、數據庫啟動的最大連接數(跟硬件的內存有關))

    2  Error: Page download timeout (120 seconds) has expired

    分析:可能是以下原因造成
    •A、應用服務參數設置太大導致服務器的瓶頸
    •B、頁面中圖片太多
    •C、在程序處理表的時候檢查字段太大多

    二.監控指標數據分析

    1.最大并發用戶數:
    應用系統在當前環境(硬件環境、網絡環境、軟件環境(參數配置))下能承受的最大并發用戶數。
    在方案運行中,如果出現了大于3個用戶的業務操作失敗,或出現了服務器shutdown的情況,則說明在當前環境下,系統承受不了當前并發用戶的負載壓力,那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。
    如果測得的最大并發用戶數到達了性能要求,且各服務器資源情況良好,業務操作響應時間也達到了用戶要求,那么OK。否則,再根據各服務器的資源情況和業務操作響應時間進一步分析原因所在。

    2.業務操作響應時間:
    • 分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖,可以確定在方案執行期間響應時間過長的事務。
    • 細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起的?問題是否與網絡或服務器有關?
    • 如果服務器耗時過長,請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能下降的原因。如果網絡耗時過長,請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題
    3.服務器資源監控指標:
    內存:
        1 UNIX資源監控中指標內存頁交換速率(Paging rate),如果該值偶爾走高,表明當時有線程競爭內存。如果持續很高,則內存可能是瓶頸。也可能是內存訪問命中率低。

        2 Windows資源監控中,如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高,同時Memory\Available bytes計數器的值持續降低,則很可能存在內存泄漏。

    內存資源成為系統性能的瓶頸的征兆:
        很高的換頁率(high pageout rate);
        進程進入不活動狀態;
        交換區所有磁盤的活動次數可高;
        可高的全局系統CPU利用率;
        內存不夠出錯(out of memory errors)

    處理器:
        1 UNIX資源監控(Windows操作系統同理)中指標CPU占用率(CPU utilization),如果該值持續超過95%,表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。如果服務器專用于SQL Server,可接受的最大上限是80-85%
        合理使用的范圍在60%至70%。
        2 Windows資源監控中,如果System\Processor Queue Length大于2,而處理器利用率(Processor Time)一直很低,則存在著處理器阻塞。

    CPU資源成為系統性能的瓶頸的征兆:   
         很慢的響應時間(slow response time)
         CPU空閑時間為零(zero percent idle CPU)
         過高的用戶占用CPU時間(high percent user CPU)
         過高的系統占用CPU時間(high percent system CPU)
        長時間的有很長的運行進程隊列(large run queue size sustained over time)

    磁盤I/O:
        1 UNIX資源監控(Windows操作系統同理)中指標磁盤交換率(Disk rate),如果該參數值一直很高,表明I/O有問題。可考慮更換更快的硬盤系統。
        2 Windows資源監控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec頁面讀取操作速率很低,則可能存在磁盤瓶徑。

    I/O資源成為系統性能的瓶頸的征兆 :
         過高的磁盤利用率(high disk utilization)
        太長的磁盤等待隊列(large disk queue length)
        等待磁盤I/O的時間所占的百分率太高(large percentage of time waiting for disk I/O)
        太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
        過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))
        太長的運行進程隊列,但CPU卻空閑(large run queue with idle CPU)

    4.數據庫服務器:
    SQL Server數據庫:
        1 SQLServer資源監控中指標緩存點擊率(Cache Hit Ratio),該值越高越好。如果持續低于80%,應考慮增加內存。
        2 如果Full Scans/sec(全表掃描/秒)計數器顯示的值比1或2高,則應分析你的查詢以確定是否確實需要全表掃描,以及SQL查詢是否可以被優化。
        3 Number of Deadlocks/sec(死鎖的數量/秒):死鎖對應用程序的可伸縮性非常有害,并且會導致惡劣的用戶體驗。該計數器的值必須為0。
       4 Lock Requests/sec(鎖請求/秒),通過優化查詢來減少讀取次數,可以減少該計數器的值。

    Oracle數據庫:
      1 如果自由內存接近于0而且庫快存或數據字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
        快存(共享SQL區)和數據字典快存的命中率:
       select(sum(pins-reloads))/sum(pins) from v$librarycache;
        select(sum(gets-getmisses))/sum(gets) from v$rowcache;
        自由內存:    select * from v$sgastat where name=’free memory’;
    2 如果數據的緩存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS參數的值(單位:塊)。
      緩沖區高速緩存命中率:
        select name,value from v$sysstat where name in ('db block gets’,
        'consistent gets','physical reads') ;
       
        Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
    3 如果日志緩沖區申請的值較大,則應加大LOG_BUFFER參數的值。
        日志緩沖區的申請情況 :
         select name,value from v$sysstat where name = 'redo log space requests' ;
    4 如果內存排序命中率小于0.95,則應加大SORT_AREA_SIZE以避免磁盤排序 。
       內存排序命中率 :
         select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
       
        注:上述SQL Server和Oracle數據庫分析,只是一些簡單、基本的分析,特別是Oracle數據庫的分析和優化,是一門專門的技術,進一步的分析可查相關資料。

    posted on 2007-12-18 13:16 josson 閱讀(593) 評論(0)  編輯  收藏 所屬分類: java 開發
    <2007年12月>
    2526272829301
    2345678
    9101112131415
    16171819202122
    23242526272829
    303112345

    常用鏈接

    留言簿(3)

    隨筆分類

    隨筆檔案

    收藏夾

    搜索

    •  

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲精品视频观看| 亚洲熟女综合色一区二区三区| 亚洲国产女人aaa毛片在线| 亚洲AV无码乱码麻豆精品国产| 一区免费在线观看| 亚欧色视频在线观看免费| 亚洲第一视频在线观看免费| 亚洲第一网站免费视频| 免费A级毛片无码A∨| 亚洲国产专区一区| 亚洲中文字幕无码久久2020| 成人免费毛片观看| 亚洲精品中文字幕乱码| 真人做人试看60分钟免费视频| 亚洲啪啪综合AV一区| 国产成人 亚洲欧洲| 精品久久久久成人码免费动漫| 亚洲人成网站在线观看播放| 日韩视频免费在线观看| 亚洲伊人久久综合中文成人网| 亚洲av无码日韩av无码网站冲| 99国产精品永久免费视频| 亚洲熟妇自偷自拍另欧美| 免费国产小视频在线观看| 亚洲最大天堂无码精品区| 国产免费小视频在线观看| 亚洲人片在线观看天堂无码| 黄页免费的网站勿入免费直接进入| 亚洲熟妇AV一区二区三区浪潮| 亚洲阿v天堂在线2017免费| 精品四虎免费观看国产高清午夜 | 四虎影视永久在线精品免费| 亚洲一区精品伊人久久伊人| 午夜精品射精入后重之免费观看| 亚洲乱码国产乱码精品精| 国产日韩精品无码区免费专区国产 | 免费无遮挡无遮羞在线看| 国产资源免费观看| 青娱乐在线免费观看视频| 国产伦一区二区三区免费| 黄色网站软件app在线观看免费|