基於web網站專案的效能測試結果分析

時念發表於2020-06-18

業務背景:

  最近公司研發了一款對併發要求比較高的web專案,需要對其壓力測試,模擬線上可能存在的問題,這個過程中遇到一些很多問題,這裡重新梳理一下思路,希望能給遇到同樣問題的小夥伴提供一個參考。

工具描述:

  壓力工具使用的是:Loadrunner

  伺服器監控使用的是:nmon

  資料庫:oracle

  web容器:Tomcat + war 

 

專案就好像是一個木桶,效能測試要找到最短的那個板,也就是系統的瓶頸,但是有些部分應用的一些引數配置可能會變成系統的瓶頸。

圈重點,以下是這個效能測試過程中踩的引數配置的坑

1、資料庫執行緒數

oracle是連線數限制的,預設是150個,如果不把這個放開,只需要超過150個連線就開始等待了,等待時間超過了,就認為失敗了。開始的時候沒有注意到這塊,連線數一直上不來,放開了就好了。
檢視當前的資料庫連線數:select count(*) from v$process ; 
修改資料庫最大連線數:alter system set processes = 300 scope = spfile;

修改完之後要重啟資料庫:
關閉資料庫:shutdown immediate;
啟動資料庫:startup;
另外測試過程需要關注資料庫的當前連線數來輔助判斷問題
當前的session連線數:select count(*) from v$session

2、tomcat連線數配置

 tomcat連線數的配置在 tomcat根目錄/conf/server.xml中,

 <Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443" URIEncoding="UTF-8" maxConnections="200" acceptCount="100"/>

   maxConnections:最大連線數

   acceptCount:最大等待數

   tomcat最大連線數取決於maxConnections這個值加上acceptCount這個值,在連線數達到了maxConenctions之後,tomcat仍會保持住連線,但是不處理,等待其它請求處理完畢之後才會處理這個請求。

3、資料庫連線池配置

    專案使用的是druid連線池,主要關注以下配置,最大連線數以及等待時間

  <!-- 配置初始化大小、最小、最大 --> 
  <property name="initialSize" value="1" /> 
  <property name="minIdle" value="1" /> 
  <property name="maxActive" value="10" />
  <!-- 配置獲取連線等待超時的時間 --> 
  <property name="maxWait" value="10000" />

 

最後補充一點系統效能的優化方案(一知半解,先列一下,後續繼續學習):

1、SQL執行效率太低

這塊可以考慮優化sql本身,比如說查詢頻繁的加索引,插入頻繁的去索引,如果都頻繁還可以考慮讀寫分離,加快取處理。

2、程式碼發生死鎖(調整程式碼業務邏輯)

在高併發測試中比較容易檢查出來的就是死鎖的問題,這塊需要開發檢查自身的程式碼邏輯,加一些事務鎖之類。

這裡附上ORACLE查詢鎖表及解鎖的SQL語句:

-- 檢視鎖表程式SQL語句:
select * from vsessiont1,vsession t1, vsessiont1,vlocked_object t2 where t1.sid = t2.SESSION_ID;

-- 檢視導致鎖表的sql語句是那一條
select l.session_id sid,
s.serial#,
l.locked_mode,
l.oracle_username,
s.user#,
l.os_user_name,
s.machine,
s.terminal,
a.sql_text,
a.action
from vsqlareaa,vsqlarea a, vsqlareaa,vsession s, v$locked_object l
where l.session_id = s.sid
and s.prev_sql_addr = a.address
order by sid, s.serial#;

–- 殺掉鎖表程式:
–- 通過上面的查詢獲取SID和serial#,替換下面的x,y,就可以解除被鎖的狀態
alter system kill session ‘x,y’;

 

新手上路,有問題歡迎指正【手動謝謝】~ 

 

相關文章