伺服器如何做壓力測試

⑴ 如何對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 上，然後直接在雲上運行。你能夠很方便的進行擴展，協同合作，並且可以得到高級的報表。

⑵ 如何用Jmeter做壓力測試

在「伺服器名稱或ip」設置127.0.0.1，埠號設置:8080，「方法」設置post，路徑設置網站登錄的地址，如「/exam/operatorAction」。

登錄需傳入用戶、密碼。在「同請求一起發送參數」列表中添加參數。參數值根據web應用設置。如login_user=0001;login_password=1;actFlag=login。

一般網站登錄後，在tomcat中生成了session，之後訪問其他頁面將無需再次登錄，前提是瀏覽器需支持cookie。在jmap中也同樣，如要繼續訪問其他頁面，還需做下面關鍵的設置。

Apache JMeter

是Apache組織開發的基於Java的壓力測試工具。用於對軟體做壓力測試，它最初被設計用於Web應用測試，但後來擴展到其他測試領域。 它可以用於測試靜態和動態資源，例如靜態文件、Java小服務程序、CGI 腳本、Java 對象、資料庫、FTP伺服器， 等等。JMeter 可以用於對伺服器、網路或對象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。

⑶ 如何做壓力測試

一個壓力測試的流程：

1、明確測試目標

2、制定測試計劃

3、實施測試，收集參數

4、分析測試結果

5、給出優化方案

一 、明確測試目標：如果是客戶的需求，那需要向客戶確認，有清楚的性能指標參數，測試時就是保證系統達到該指標並能良好運轉，即壓力測試。如果是自己的系統需要有一個評估，那就需要完整的得到該系統的幾個臨界點，拿到完整的性能曲線，從而來分析部署情況，即為性能測試。不管是哪個，知道了需求，才能制定計劃。

性能測試的目標是發現重大的系統瓶頸。你可以想像一個系統由一系列的瓶頸組成；發現並改善一個瓶頸往往會在其他地方產生一個新的瓶頸。例如，我曾為一運行微軟Windows CE的器件部門工作。我們發現的第一大性能問題體現在某一具體硬體環境下的內存管理中。我們把問題分離出來，改善了內存分配的效率。爾後再次運行我們的測試，又找到了一個新的瓶頸，這次體現在網路吞吐量上（throughput）。解決了這個問題後，我們接著又為下一個瓶頸改善而工作，然後再下一個，直到整個系統都達到了性能目標。要記住的是：關鍵在於要盡早訂立性能目標，否則你可能不知道什麼時候該停止性能測試。

二、制定測試計劃：確定使用什麼工具，著重哪些參數，設置線程數，方法執行次數，執行時間，是否多個介面同時進行測試等等。

三、實施測試，收集參數：選一個施壓工具，來向部署好的服務發起高並發請求，同時關注和收集性能參數。這個是我們花費時間最多的地方。通常該階段需要反復執行，來得到想要的數據。通常來說，我們可以使用JMeter LR AB 自己寫多線程等各種方式，之後介紹一下JMeter。

四、分析測試結果：即根據上一節的參數介紹來進行參數分析。

五、給出優化方案：如果是代碼邏輯耗費cpu，就優化演算法；如果是redis等資料庫耗時，就增加節點，減少讀取，讀寫分離，使用內存等；如果是外在條件限制，則與外部們溝通問題，共同優化等等。

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

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

⑸ jmeter模擬對網站做壓力測試

一般的網站，在進入業務功能前先需登錄，然後才能訪問業務功能。基本框架如下

詳細步驟：

1 .用badboy錄制登錄，訪問隨意一個網址。

2.用jmeter打開，一會自己寫的時候可以參考裡面的參數名稱或路徑什麼的。如果對http熟悉可以省略這兩部直接寫腳本

3.新建一個線程組

選擇 測試 計劃，按右鍵－》添加－》threads（users）線程組

線程組能設置以多少個線程並發做壓力測試。在」循環次數」設置不選擇永遠，循環次數設置1。

4.設置登錄http請求，選擇線程組，右鍵――添加――》sampler－―》http 請求。

在「伺服器名稱或ip」設置localhost或網址，埠設置:80，「方法」設置post，路徑設置網站登錄的地址。登錄需傳入用戶、密碼。在「同請求一起發送參數」列表中添加參數。參數值根據web應用設置。如login_user=0001;login_password=1;actFlag=login。具體怎麼設置可以拷貝剛才錄制的內容。

5.登錄成功後，網站一般將跳入主頁面。在jmap中可做判斷，判斷是否登錄後按預想進入主頁面（此步驟也可不設）。選擇4中的「http請求「，右鍵――》添加――》斷言――》響應斷言。「Apply to」設置Main smaple only；「要測試的響應欄位」設置「url樣本」；「模式匹配規則」設置「包括」，「要測試的模式」增加頁面跳轉到的主頁面

6.一般網站登錄後，在tomcat中生成了session，之後訪問其他頁面將無需再次登錄，前提是瀏覽器需支持cookie。在jmap中也同樣，如要繼續訪問其他頁面，還需做下面關鍵的設置。

選擇「線程組」――》右鍵――》添加――》配置元件――》Http cookie管理器。加了此步驟後，http請求將具備cookie功能，即登錄成功後訪問其他頁面將不會跳轉到登錄頁面重新登錄。

7.對目標頁面反復壓力測試。

7.1 如何使被測頁面反復訪問達到測壓效果。選「線程組」―》右鍵――》邏輯控制源嘩旁器――》循環控制器。循環次數中選擇「永遠」。

7.2 選擇剛加的「循環控制器」，右鍵――》添加――》sampler－―》http 請求，按4步驟設置ip、埠，http請求方法為「get」，路徑為被壓力測試的url

按上面的設置後，已完成配置，可做壓力測試。只需點菜單「運行」――》啟動，即運行壓力測試。

8.jmeter提供了許多壓力結果查看工具。是壓力測試時非常好的分析工具。下面幾種查看工具可有選擇的添加。

8.1 察看結果樹。他記錄每次請求發送數據、雹橡響應返回數據。選擇「線程組」――》右鍵――》添加――》察看結蘆橘果樹。

8.2 用表格查看結果。可查看每次請求的響應時間等。選擇「線程組」――》右鍵――》添加――》用表格查看結果。

8.3 Summary Report。可查看平均響應時間、最長響應時間等。

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

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

⑺ 如何對伺服器進行壓力測試

http_load是基於Linux平台的一種性能測工具。它是以並行復用的方式運行，僅適用於Web頁面的性能測試，不適用於訪問資料庫，而且測試結果分析是有限的，平台依賴Linux 。http_load可以簡單地通過txt文本文件中記錄的參數來對HTTP伺服器進行壓力測試，那是如何對伺服器進行壓力測試的呢?下面我們就來介紹 Linux中如何安裝使用http_load對伺服器進行壓力測試的教程。 具體方法步驟如下： 1、下載 官方網站：acme/software/http_load/http_load-12mar2006.tar.gz tar xzf http_load-12mar2006.tar.gz 2、安裝 代碼如下： cd http_load-12mar2006 make 執行完make，會在當前目錄生成一個http_load二進制文件。 3、使用方法 代碼如下： root@www：~/http_load-12mar2006# 。/http_load --help usage： 。/http_load [-checksum] [-throttle] [-proxy host:port] [-verbose] [-timeout secs] [-sip sip_file] -parallel N -rate N [-jitter] -fetches N -seconds N url_file One start specifier， either -parallel or -rate， is required. One end specifier， either -fetches or -seconds， is required. 主要參數說明： -parallel 簡寫-p ：含義是並發的用戶進程數。 -rate 簡寫-r ：含義是每秒的訪問頻率 -fetches 簡寫-f ：含義是總計的訪問次數 -seconds簡寫-s ：含義是總計的訪問時間 選擇參數時，-parallel和-rate選其中一個，-fetches和-seconds選其中一個。 4、示例： 代碼如下： http_load -parallel 50 -s 10 urls.txt 這段命令行是同時使用50個進程，隨機訪問urls.txt中的網址列表，總共訪問10秒。 代碼如下： http_load -rate 50 -f 5000 urls.txt 每秒請求50次，總共請求5000次停止。 測試網站每秒所能承受的平均訪問量： 代碼如下： http_load -parallel 5-fetches 1000urls.txt 這段命令行是同時使用5個進程，隨機訪問urls.txt中的網址列表，總共訪問1000次。運行之後的結果： 1000 fetches， 5 max parallel， 6e+06 bytes， in 58.1026 seconds 6000 mean bytes/connection 17.2109 fetches/sec， 103266 bytes/sec msecs/connect： 0.403263 mean， 68.603 max， 0.194 min msecs/first-response： 284.133 mean， 5410.13 max， 55.735 min HTTP response codes： code 200 — 1000 從上面的運行結果來看，目標網站僅僅能夠承受每秒17次訪問，不夠強壯。