bat怎麼對伺服器進行壓力測試

A. 如何對Tomcat服務進行壓力測試

英文原文

如果你在測試一個由Tomcat servlet容器（或者Apache web伺服器）組成的環境時，你很可能會碰到瓶頸，因為Tomcat servlet容器使用Apache JServ Protocol - AJP。所以，如果想要評估Tomcat引擎的性能的話，最合適的方式就是使用相同的AJP協議。

使用 Apache JMeter ，你可以通過采樣器（sampler）模擬發送AJP請求並返回結果 -- 也就是AJP/1.3采樣器。你也可以用這個JMeter采樣器來壓測WildFly，Jetty和GlassFish servlet等Web容器，它們都是用AJP協議。這篇文章將會講解如何來進行測試。

AJP是一個致力於從web伺服器路由請求到應用伺服器的二進制通信協議。在web伺服器和應用伺服器之間通信，AJP協議比HTTP協議更加高效，因為它是使用了壓縮的二進制協議。例如，對於一個請求方法（「POST」或者「GET」），AJP只需要一個位元組來表示，並且每個請求頭只需要兩個位元組。所以，需要發送的信息大大減少，也就是得每個請求的處理也更快。

請求的處理大致如下：

對於這樣的應用架構，JMeter AJP/1.3 采樣器可以通過在你的系統上建立AJP連接，然後發送AJP請求到應用伺服器，從而進行壓測達到查找應用瓶頸的目的。

目前有3個版本的AJP協議 -- 1.2（廢棄的），1.3 和 1.4（實驗版本）。JMeter的AJP/1.3采樣器支持1.3版本的AJP協議。

現在，我們來演示如何使用它。

AJP/1.3 采樣器可以將這里設置的HTTP請求轉換成AJP請求。正如你所看到的，它的界面和HTTP采樣器的十分相似。

AJP 采樣器有一個限制 -- 當前版本的實現不支持在一個請求里上傳多個文件。只有第一個文件會被上傳。必須使用多個AJP 采樣器來上傳多個文件。

現在，讓我們來看看AJP 采樣器在JMeter腳本里是如何工作的。首先，我們先在本地機器上啟動一個Tomcat實例，然後配置它來發送POST請求。 Tomcat 9 默認就帶了一些servlet示例，可以用來測試AJP請求。

我們的測試場景是：

接下來，我們會使用 AJP 采樣器 來產生同樣的請求。

在前面的章節里，我們的servlet可以接受兩個參數並在結果里返回它們的值。現在，我們使用AJP 采樣器來發送帶參數的AJP POST請求，通過JMeter執行，並在相應結果里拿到我們在請求里設置的參數。

設置完成後的采樣器如下：

6.現在，我們可以運行結果，並在監聽器里查看結果。

現在，可以看到我們的采樣器已經順利地把帶有我們設定的參數的AJP請求發送到我們的伺服器上。並且，可以看到之前設置的參數都列在「Paramater in this request」部分 -- 這意味著我們的服務已經收到我們的請求了。

恭喜！你現在知道怎麼壓測AJP協議以及Tomcat服務了。為了更加方便地去執行你的測試，你可以將腳本上傳到 BlazeMeter 上，然後直接在雲上運行。你能夠很方便的進行擴展，協同合作，並且可以得到高級的報表。

B. 怎樣測試伺服器壓力

下載並安裝WAST；

1．設置並行連接數；

2．設置持續時間；

3．其餘設置；

註：所有以上的選項可以根據自己的需要進行設置。

設置完成後就可以進行壓力測試。測試的步驟如下：

第一步，點擊工具欄上的「New Script」按鈕，在打開的面板中點擊「Nanual」按鈕創建一個新的測試項目。在打開的窗口中對它進行設置，在主選項中的Server中填寫要測試的伺服器的IP地址。這里我們填寫192.168.1.20。在下方選擇測試的Web連接方式，這里的方式Verb選擇get。Path選擇要測試的Web頁面路徑，這里填寫/Index.asp即動網的首頁文件，WAST可以設置更多的Path。

第二步，在「Settings」功能設置中將Stress Level （Threads）線程數設置為1000。然後點工具中的灰色三角按鈕即可進行測試。測試過程中我們可以從伺服器的任務管理器中看到CPU使用率已經達到100%，損耗率達到最大。在CMD窗口中使用命令netstat -an，可以看到客戶端的IP地址在伺服器上的80埠進行了非常多的連接，而且Web網站已經打不開了，提示過多用戶連接。

C. 多台伺服器負載均衡的壓力測試要怎麼做

負載均衡是演算法上的問題，按常規軟體測試的方式來。
如果負載沒問題，那理論上壓力測試只要測單個服務就行了。

D. 如何用Jmeter做壓力測試

如何用Jmeter做壓力測試

Jmeter是一個性能測試工具，同loadrunner類似，他功能較多，我們常用的功能是用jmeter模擬多瀏覽器對網站做壓力測試。
下載jmeter地址 ：http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi
我們一般的網站，在進入業務功能前先需登錄，然後才能訪問業務功能。下面介紹如何用jmeter登錄系統再對主業務做壓力測試。
1. 運行jmeter
2. 左邊樹將出現測試計劃、工作台兩根節點。
3. 選擇測試計劃，按右鍵－》添加－》threads（users）線程組
線程組能設置以多少個線程並發做壓力測試。
在」循環次數」設置不選擇永遠，循環次數設置1。
4. 現在先介紹如何設置登錄http請求，選擇線程組，右鍵――添加――》sampler－―》http 請求。
http請求即模仿瀏覽器的訪問。
在「伺服器名稱或ip」設置127.0.0.1，埠號設置:8080，「方法」設置post，路徑設置網站登錄的地址，如「/exam/operatorAction」。
登錄需傳入用戶、密碼。在「同請求一起發送參數」列表中添加參數。參數值根據web應用設置。如login_user=0001;login_password=1;actFlag=login
5. 登錄成功後，網站一般將跳入主頁面。在jmap中可做判斷，判斷是否登錄後按預想進入主頁面（此步驟也可不設）。選擇4中的「http請求「，右鍵――》添加――》斷言――》響應斷言。「Apply to」設置Main smaple only；「要測試的響應欄位」設置「url樣本」；「模式匹配規則」設置「包括」，「要測試的模式」增加頁面跳轉到的主頁面，如：「studentMain.jsp」
6. 一般網站登錄後，在tomcat中生成了session，之後訪問其他頁面將無需再次登錄，前提是瀏覽器需支持cookie。在jmap中也同樣，如要繼續訪問其他頁面，還需做下面關鍵的設置。
選擇「線程組」――》右鍵――》添加――》配置元件――》Http cookie管理器。加了此步驟後，http請求將具備cookie功能，即登錄成功後訪問其他頁面將不會跳轉到登錄頁面重新登錄。
7. 對目標頁面反復壓力測試。
7.1 如何使被測頁面反復訪問達到測壓效果。選「線程組」―瞎磨》右鍵――》邏輯控制器――》循環控制器。循環次數中選擇「永遠」。
7.2 選擇剛加的「循環控制器」，右鍵――》添加――》sampler－―》http 請求，按4步驟設置ip、埠，http請求方法為「get」，路徑為被壓力測試的url，如：「exam/business/studentExam.action.StudentExamAction?action=goIntoMockExam」。
按上面的設置後，已完成配置，可做壓力測試。只需點菜單「運行」――》啟動，即運行壓力測試。
8. jmeter提供了許多壓力結果查看工具。是壓力測試時洞核非常好的分析工具。下面幾種查看工具可有選擇的添加。
8.1 察看結果樹。他記錄每次請求發送數據、響應返回數據。選擇「線程組」――》右鍵――》添加――》察看結果樹。
8.2 用表格查看結果。可查看每次請求的響應時間等。選擇「線程組」――》右鍵――》添加――》用表格查看納神掘結果。
8.3 Summary Report。可查看平均響應時間、最長響應時間等。

E. 如何寫一個bat文件要求用戶輸入兩個參數

方法和詳細的操作步驟如下：

1、第一步，創建兩個bat文件進行測試，見下圖，轉到下面的步驟。

F. jmeter壓力測試實現負載均衡

文章來源於：https://blog.csdn.net/russ44/article/details/54729461

Jmeter 是java 應用，對於CPU和內存的消耗比較大，因此，當需要模擬數以千計的並發用戶時，使用單台機器模擬所有的並發用戶就有些力不從心，甚至會引起JAVA內存溢出錯誤。為了讓jmeter工具提供更大的負載能力，jmeter短小精悍一有了使用多台機器同時產生負載的機制。

那麼，是如何實現多台負載機同時運行的呢？當然不會多個人坐在多台負載機面前，一喊開始，大家同時啟動jmeter。這種方式很笨，也很難達到真正的同步。其實，我們通過單個jmeter 客戶友態端就可以控制多個遠程的jmeter伺服器，使它們同步的對伺服器進行壓力測試。

通過遠程運行jmeter，好攔源測試人員可以跨越多台低端計算機復制測試，這樣就可以模擬一個比較大的伺服器壓力，一個jmeter客戶端實例，理論上可以控制任意多的遠程jmeter實例，並通過他們收集測試數據。這樣一樣，就有了如下特性：

*  保存測試采樣數據到本地機器

*  通過單台機器管理多個jmeter執行引擎。

*  沒有必要將測試計劃復制到每一台機器，jmeter GUI客戶端會將它發往每一台jmeter伺服器。

*  每一台jmeter遠程伺服器都執行相同的測試計劃，jmeter不會在執行期間做負載均衡，每一台伺服器都會完整地運行測試計劃。

在1.4G Hz～3GHz 的CPU 、1GB 內存的 JMeter 客戶端上，可以處理線程 100～300。但是Web Service 例外。XML處理是 CPU 運算密集的，會迅速消耗掉所有的CPU 。一般來說，以XML技術為核心的應用系統，其性能將是普通Web 應用的 10%～25% 。另外，如果所有負載由一台機器產生，網卡和交換機埠都可能產生瓶頸，所以一個JMeter 客戶端線程數不應超過 100 。

採用JMeter 遠程模式並不會比獨立運行相同數目的非GUI 測試更耗費資源。但是，如果使用大量的JMeter 遠程伺服器，可能會導致客戶端過載，或者網路連接發生擁塞。

使用多台機器產生負載的操作步驟如下：

（1）在所有期望運行jmeter作為 負載生成器的機器上安裝jmeter， 並確定其中一台機器作為 controller ，其他的的機器作為agent 。

（2）衡虛 運行所有 agent 機器上的jmeter-server 文件（假定使用兩台機器192.168.9.99 和192.168.9.130 作為agent）

（3）在controller機器的jmeter的bin目錄下，找到jmeter.properties 文件，編輯該文件：

查找：

remote_hosts=127.0.0.1

修改為：

remote_hosts=192.168.9.99:1099,192.168.9.130:1099

這里要特別注意埠後，有些資料說明埠1644為jmeter的controller 和agent 之間進行通信的默認RMI埠號，但是在測試時發現，設置為1644運行不成功，改成1099後運行通過。另外還要留意agent的機子是否開啟了防火牆等。

（4）啟動controller 機子上的jmeter應用jmeter.bat，選擇菜單「運行」--->「遠程啟動」，來分別啟動agent ，也可以直接選擇「遠程全部啟動」來將所有的agent啟動。

遇到的常見問題：

1、在Controller端上控制某台機器Run，提示"Bad call to remote host"。

解決方法：檢查被控制機器上的jmeter-server有沒有啟動，或者JMeter.properties中remote_hosts的配置錯誤。

2、Agent機器啟動Jmeter_server.bat時，後台提示："could not find ApacheJmeter_core.jar"

解決方法：確定在Agent機器安裝jdk，並設置環境變數

3、遠程啟動時，報錯：

ERROR - jmeter.gui.action.RemoteStart: Failed to initialise remote engine java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:

java.net.ConnectException: Connection refused: connect

at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)

at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)

at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)

at sun.rmi.server.UnicastRef.newCall(Unknown Source)

at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)

at java.rmi.Naming.lookup(Unknown Source)

at org.apache.jmeter.engine.ClientJMeterEngine.getEngine(ClientJMeterEngine.java:54)

at org.apache.jmeter.engine.ClientJMeterEngine.(ClientJMeterEngine.java:67)

at org.apache.jmeter.gui.action.RemoteStart.doRemoteInit(RemoteStart.java:180)

at org.apache.jmeter.gui.action.RemoteStart.doAction(RemoteStart.java:80)

at org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:81)

這個問題終於被我解決了，其實原因好簡單呀。只要將本機的jmter-server.bat執行即可。要是在jmeter.properties配置的地方寫了127.0.0.1 的話 就要開本機的 jmeter-sever.bat. 不寫的話 就不用開了

4、查看1099埠是否被佔用

netstat -ano | findstr "1099"

tasklist | findstr "1099"

其它說明：

1、調度機(master)和執行機(slave)最好分開，由於master需要發送信息給slave並且會接收slave回傳回來的測試數據，所以mater自身會有消耗，所以建議單獨用一台機器作為mater。

2、參數文件：如果使用csv進行參數化，那麼需要把參數文件在每台slave上拷一份且路徑需要設置成一樣的。

3、每台機器上安裝的Jmeter版本和插件最好都一致，否則會出一些意外的問題。

G. 分布式壓測怎麼做

1、Jmeter分布式測試時，選擇其中一台作為控制機(Controller)，其它機器做為代理機(Agent)。
2、執行時，Controller會把腳本發送到每台Agent上，Agent 拿到腳本後開始執行，Agent執行時不需要啟動Jmeter，只需要把jmeter-server.bat文件打開，它應該是通過命令行模式來執行的。
3、執行後，Agent會把結果回傳給Controller，Controller會收集所有Agent的信息並匯總

步敬纖喚驟
1.CMD里輸入IPCONFIG查出IP地址

2.執行機：打開Jmeter/bin/jmeter.properties，找到」remote_hosts=127.0.0.1」,把這一行修改為」remote_hosts=192.168.8.149：豎碰1099,1099是埠號，可以隨意自定義。啟動執行機jmter-server.bat 執行機就算完成了

3.控制機：打開Jmeter/bin/jmeter.properties，找到」remote_hosts=127.0.0.1」,把這一行修改為」remote_hosts=192.168.8.149：1099,192.168.8.174：1099，1099是埠號，可以隨意自定義。如果有多台代理機，這里需要把所有的代理機的IP地址和埠號都加進來，用逗號分隔。
啟動控制機 jmeter-server.bat

1.添加線程組 設置線程組100 循環次數2
寫好請求--添亮凱加好斷言以及聚合報告

2.點擊菜單欄運行

3.查看聚合報告

H. 游戲上線前伺服器壓力測試應該怎麼做

對於游戲後台性能，評測標准不只單單是TPS（每秒處理多少個XX請求），因為當你的游戲伺服器上線後，不存在一群玩家只發XX請求的壓力場景。所以，游戲後台受到的現網請求壓力永遠是多場景混合的，在這樣的壓力下，後台能支撐多少人同時在線，才是一個游戲壓測者需要得到的有價值的測試結論。
要得到可支撐的"最大同時在線人數"，主要做好2件事：
1、設計你的類現網壓力模型
在現網真實壓力里，不瞎卜論壓力大小如何變化，現網環境如何變化，一個游戲類型和玩法設計定型後，永遠有2個壓力宏觀數據保持不變：a. 各介面的壓力比例不變， b.玩家平均每分鍾操作頻率不變。因此，壓力測試目標就轉變成了如何模擬符合ab數據的壓力。
對於a，首先從同類型游戲或者本游戲內測階段，日誌插樁，收集各個介面的調用比例；然後，將介面比例轉化為場景比例，如同時會有個2%完結登陸、15%玩家戰斗余神粗、20%玩家拉取好友列表、10%玩家賭博（一個手游場景例子）。
對於b，同樣在內測階段收集玩家平均操作頻率。
此時有了a和b，就可以構造出一分鍾豎鎮內玩家同時在線的真實壓力模型了。
2、用壓測工具構造出符合壓力模型的壓力
這個可以自己寫，也可以使用現成的壓測工具。現在市面上的壓測工具很多，但很多都是專注於TPS這個參數，不符合游戲行業壓測的關注點，同時在線人數。

I. web壓力測試 要測試哪些方面

web壓力測試通過產生真實壓力來發現問題需要關注以下方面：
1、對要測試的系統進行分析，明確需要對哪一塊做壓力測試。比如：淘寶網站雙十一期間，秒殺跟支付，此模式用戶操作中佔比比較大
再比如：游戲，登錄--開始戰斗--結束戰斗這種混合模式在用戶操作中佔比較大
那麼就可以針對這種佔比比較大的模式進行壓力測試
2、明確了要測試的點後，如何對這些測試點進行施壓呢？
第一種方式可以通過寫腳本產生壓力機器人對伺服器進行發包收包操作；
第二種方式就是藉助一些壓力測試工具如:JMeter或LoadRunner
3、如何對這些測試點進行正確的施壓呢？
那麼就需要用壓力測試工具或者其它方法來錄制腳本，模擬用戶的操作
4、對測試點該施加多大的壓力比較合適？該施加多少的數據才能找出系統的瓶頸？
那麼就需要明確壓力測試所限制的數量，即用戶並發量，這里分3種情況來明確：
1）根據上級的明確規定數量，來設定最確大值，然後根據情況往上或往下增減
2）上級未規定，由自己判斷，從1開始慢慢遞增。如：1，5，10，20等等
3）若做過壓力測試，則可以根據上次的壓力測試結果為基數進行測試
5、測試完之後，如何通過這些數據來定位性能問題呢？
雖然通過這些測試結果我們可以得到TPS(吞吐量)，平均響應時間等這些數據，可判斷出伺服器是否存在問題，但卻不能定位問題。

J. 網站伺服器如何做訪問壓力測試

網站伺服器的壓力測試我覺得主要有一些幾點。
1.協議這邊基本上以http或者https為主了，如果使用其他協議需要分析其打解包的方法。
2.要產生一定的壓力，壓力源這邊一定要有保證。一般都是用機器人來模擬壓力，關於機器人的邏輯可以根據具體業務來開發。
3.需要觀察在一定壓力下，伺服器的各項性能指標（cpu，內存，IO，網路流量）進行觀察，比如內存是否有泄漏，cpu利用率過高的情況。
4.壓力測試應該是一個持續性的過程，在這個過程中需要統計伺服器的性能數據，包括tps，以及機器的負載情況等。據此可以分析伺服器的瓶頸在何處，後續可以針對優化。
5.目前大部分的伺服器都部署在Linux系統上，測試同學還需要掌握相關的Linux命令以便可以更好的測試。
如果你覺得前面的太麻煩，可以來WeTest伺服器壓力測試高並發，實時性能報表，專家級性能優化建議，目前我們正在做網站壓測這一塊，你要做的僅僅是填下被測的URL即可，壓力源、數據統計這些瑣碎的工作交給我們就行了。