Ⅰ 如何對web應用程序進行負載測試
1. "簡單"的應用,可以用apache自帶的工具ab測試. 也可以試試http_load;
2. 一般給一個大概的性能評測報告,評估需要多少伺服器. 多點餘量無妨;
3. 注意記錄好各種數據. 在什麼時候需要增加伺服器更多的是考驗運維的能力.
Ⅱ 如何測試伺服器
一、伺服器測試方法分為兩個大方面，性能測試與功能測試。
在性能測試方面採用了新的測試方法，主要分為文件測試、資料庫性能測試與Web性能測試三個方面。其中，文件性能與資料庫性能採用美國Quest軟體公司的Benchmark Factory負載測試和容量規劃軟體，Web性能測試則使用了Spirent公司提供的Caw WebAvalanche測試儀。
Ⅲ 如何對Web應用程序進行負載測試
定義測試策略 到目前為止，您肯定參加過這樣的會議，客戶倚靠在寬大的會議桌上，問您：「這個系統能處理上千個用戶嗎？」傳統的負載測試方法要求您編寫腳本並執行測試，以試圖給出此問題的精確答案。對於這種測試，您需要定義「處理」的含義以及 1000 名典型用戶在站點活動時的情形。您需要定義測試用例以代表各種用戶活動：例如，購買股票或注冊新的帳戶。接下來，您必須估計用戶在這些測試用例上的分布。對以下數據進行假設，即模擬真實用戶與應用程序交互時，需要多長的思考時間（或等待時間）。因此，負載測試期間活動的可從某個方面大致反映出同樣數量的真實用戶在站點活動時的情形。 這種方法有幾個不足之處。首先，其結果不會比您做的假設更好。顯然，不正確的假設將使結果出現偏差。 其次，估計真實用戶需要大量客戶端硬體。如果對每名虛擬用戶給定需要的處理能力和內存量，則典型的客戶端計算機可以處理大約 200 名虛擬用戶。因此，對 2000 名用戶並發處理級別的測試需要 10 台客戶端計算機 — 這是一筆重大投資。測試使用 HTTPS 的站點將需要多得多的客戶端硬體。 最終，此方法難以向您的開發團隊提供以操作為導向的信息。當某處出現故障時，常常難以再現該問題。 作為備選方案，我們建議您圍繞以下這些關鍵問題設計測試用例： �6�1 系統瓶頸在哪裡？系統能同步處理多少個並發請求？ �6�1 在響應時間變得不可接受之前，一台機器能處理多少名不同步的超級用戶？ �6�1 添加額外的硬體時，結果是線形增長的嗎？ �6�1 有任何穩定性問題會妨礙站點運行於生產環境中嗎？ 此方法將使用開發團隊（此開發團隊參與可能出現問題的領域）提供的附加信息。請關注這些領域。對於上一個示例，其瓶頸可能出在定單提交領域。從這里您可以派生出更具體的問題，例如「提交流程可以同時處理多少個請求？」攻擊這些特定領域是最快且成本最小的方法，用來向開發團隊提供以操作為導向的信息，以便他們能改進系統。在使用這種方法的同時，我們推薦您記住遵循以下建議。 關注負載測試正如我們已提到的那樣，首先要做的是構建導致潛在瓶頸和穩定性問題的腳本。這種「數據第一，假設第二」的方法使您能夠從應用程序收集原始數據，然後根據假設確定更高級別的結果。不用擔心為識別低風險站點的腳本編寫問題。例如，為站點的幫助領域或只讀文檔領域編寫腳本不大可能出現系統瓶頸。 同步請求使用同步請求攻擊瓶頸。此處的這個主意是模擬最壞的情況：即，站點上的用戶精確地在同一時間攻擊瓶頸。通過使用戶同步，您可以重復進行此測試。如果不同步結果，則難以再現故障情況。可以使用同步點做到這一點，同步點是大多數較健壯（成本也較高）的測試工具中提供的一項功能。同步點迫使每名虛擬用戶一直等到剩餘的用戶到達腳本中定義的點後，才能開始下一請求。它允許您精確並重復地確定站點的潛在瓶頸區域能處理的並發用戶數。例如，下限可以是 7 名並發同步用戶。 創建循環測試用例腳本使測試用例循環。在另一種方法中，每次測試用例迭代前後，站點應處於相同狀態。這允許您長時間地重復運行測試用例。 使用超級用戶最後，使用我們所稱的超級用戶。正如前面所提到的，超級用戶運行時思考時間設置為零。請記住，思考時間假設是用於常規測試中，以使虛擬用戶模擬真實用戶。但是，如果將虛擬用戶思考時間減半，則伺服器的實際負載將加倍。在另一種方法中，伺服器真正關心的與負載有關的變數是每秒的請求數。虛擬用戶的數量及其思考時間結合起來生成該負載。 讓我們進行一些數學運算以使此概念更清晰。下面的公式計算訪問站點的真實用戶生成的負載（請求數/秒）： 例如，某個站點有 100 名並發用戶，假設下載時間為 10 秒，思考時間為 30 秒，則每秒將生成 2.5 頁。如果我們假設每頁 3 個請求，則在 Web 伺服器上將轉化為每秒 7.5 個請求。 以超級用戶運行測試時，觀察每秒請求數，並與剛剛計算的值比較。根據我們的經驗，真實用戶數與超級用戶數的比例通常約為 15:1。對於同一個示例，這意味著 (100/15) 名超級用戶將生成與 100 名普通用戶相同的負載。再舉一個例子，假設在 10 名超級用戶之後響應時間變得不可接受。請注意轉換回真實用戶數的該點每秒請求數。現在您可以進行任何希望的思考時間假設，甚至可以更改它而無需重新運行測試。在幾天的測試之後，您將能根據直覺從超級用戶數轉換成真實用戶數。此方法允許您保持用戶數可控，減少所需的客戶端硬體數量，並包含負載測試軟體的成本。 這些超級用戶測試用例對於多機測試很有用。要測試站點的可伸縮性，可添加第二台 Web 伺服器和一個負載平衡器，並重復超級用戶測試。理想情況下，在看見相同的相應次數之前，您將能加倍超級用戶數量。 要回答穩定性問題，可運行測試，以在延長的時間段內維持合理數量的並發且未同步超級用戶。我們在上一個項目中熬了很多個通宵，甚至 24 小時晝夜不停，但持續時間與應用程序有關。我們稱之為「內置」測試。一旦您已採取步驟識別並潛在地解決了找到的瓶頸，則重復同步點測試，看下限是否有所增長。然後用所支持的新的並發用戶數重新運行「內置」測試。以努力提高此數字為目標重復該循環，直到達到質量條。 但是有多少用戶呢？ 盡管此方法向開發團隊提供了有價值的信息，但它使得您更難於回答會議室的問題。不過，您可以近似地估計答案。例如，假設站點的最壞情況瓶頸顯示，每台計算機多於 20 名超級用戶的情況下，響應時間超過 10 秒。根據您從我們建議的公式計算的結果，近似地估計有 300 名真實用戶（20 名超級用戶 × 15 名真實用戶）。此時，您可以做出與常規用例中相同的假設。通常情況下，有百分之多少的用戶正在使用站點的此領域？假設預期 50% 的用戶正在使用此領域，而其他領域，例如文檔或資料庫讀取，用戶比例則沒有這么大。這意味著具有一台 Web 伺服器的系統將處理大約 600 名用戶。 到目前為止，我們已討論了在能明確地指向站點的一個瓶頸領域的情況下該如何做，但如果影響性能的領域不止一個時您又應如何做呢？答案是創建單獨查看各個領域的測試腳本。首先孤立地運行這些腳本，然後一起運行。再比較結果，看站點的一個領域對另一個領域的影響有多大。
Ⅳ web壓力測試 要測試哪些方面
web壓力測試通過產生真實壓力來發現問題需要關注以下方面：
1、對要測試的系統進行分析，明確需要對哪一塊做壓力測試。比如：淘寶網站雙十一期間，秒殺跟支付，此模式用戶操作中佔比比較大
再比如：游戲，登錄--開始戰斗--結束戰斗這種混合模式在用戶操作中佔比較大
那麼就可以針對這種佔比比較大的模式進行壓力測試
2、明確了要測試的點後，如何對這些測試點進行施壓呢？
第一種方式可以通過寫腳本產生壓力機器人對伺服器進行發包收包操作；
第二種方式就是藉助一些壓力測試工具如:JMeter或LoadRunner
3、如何對這些測試點進行正確的施壓呢？
那麼就需要用壓力測試工具或者其它方法來錄制腳本，模擬用戶的操作
4、對測試點該施加多大的壓力比較合適？該施加多少的數據才能找出系統的瓶頸？
那麼就需要明確壓力測試所限制的數量，即用戶並發量，這里分3種情況來明確：
1）根據上級的明確規定數量，來設定最確大值，然後根據情況往上或往下增減
2）上級未規定，由自己判斷，從1開始慢慢遞增。如：1，5，10，20等等
3）若做過壓力測試，則可以根據上次的壓力測試結果為基數進行測試
5、測試完之後，如何通過這些數據來定位性能問題呢？
雖然通過這些測試結果我們可以得到TPS(吞吐量)，平均響應時間等這些數據，可判斷出伺服器是否存在問題，但卻不能定位問題。
Ⅳ php web伺服器。網站上線在即，請問如何測試伺服器壓力呢比如如何知道這個網站到底能同時承受
利用一些軟體吧，可用來進行 Web 壓力測試的工具有很多，比如微軟的 Web Application Stress、Linux下的 siege、功能全面的 Web-CT 等等，這些都是非常優秀的 Web 壓力測試工具。
一、 Siege
一款開源的壓力測試工具，可以根據配置對一個WEB站點進行多用戶的並發訪問，記錄每個用戶所有請求過程的相應時間，並在一定數量的並發訪問下重復進行。
官方：http://www.joedog.org/
1. 下載源碼
請自行google例如:
wget http://soft.vpser.net/test/siege/siege-2.67.tar.gz
2. 解壓、編譯和安裝
tar -zxf siege-2.67.tar.gz cd siege-2.67/ /configure make && make install
3. 運行siege
siege -c 200 -r 10 -f test.txt
-c是並發量，-r是重復次數。 url文件就是一個文本，每行都是一個url，它會從裡面隨機訪問的。
test.txt 內容:
http://blog.test.com/wp-content/uploads/2012/07/cluster6.png
http://blog.test.com/wp-content/uploads/2012/07/cluster7-150x150.png
http://blog.test.com/wp-content/uploads/2012/07/cluster7.png
http://blog.test.com/wp-content/uploads/2012/07/cluster8-150x150.png
http://blog.test.com/wp-content/uploads/2012/07/cluster9-150x150.png
4 結果說明
Lifting the server siege… done.
Transactions: 3419263 hits //完成419263次處理
Availability: 100.00 % //100.00 % 成功率
Elapsed time: 5999.69 secs //總共用時
Data transferred: 84273.91 MB //共數據傳輸84273.91 MB
Response time: 0.37 secs //相應用時1.65秒：顯示網路連接的速度
Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次處理：表示伺服器後
Throughput: 14.05 MB/sec //平均每秒傳送數據
Concurrency: 213.42 //實際最高並發數
Successful transactions: 2564081 //成功處理次數
Failed transactions: 11 //失敗處理次數
Longest transaction: 29.04 //每次傳輸所花最長時間
Shortest transaction: 0.00 //每次傳輸所花最短時間
二、Webbench
webbench最多可以模擬3萬個並發連接去測試網站的負載能力，安裝使用簡單方便。
1. 下載源碼
請自行google例如:
wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
2. 解壓、編譯和安裝
tar zxvf webbench-1.5.tar.gz cd webbench-1.5 make mkdir /usr/local/man #建立相應目錄否則導致無法正常安裝 make install
3. 運行webbench
webbench -c 100 -t 30 http://192.168.1.235/index.html
-c表示並發數，-t表示時間(秒)
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.235/index.html
100 clients, running 30 sec.
Speed=16084 pages/min, 152872 bytes/sec. #運行結果顯示
Requests: 8042 susceed, 0 failed.
三、Web Application Stress Tool
這是由微軟的網站測試人員開發的專門用來進行實際網站壓力測試以一套工具。透過這套功能強大的壓力測試工具，管理人員可以在網站實際上線之前先網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調整、設置工作。