如何判斷web伺服器支持用戶在線

『壹』 怎樣模擬多用戶登錄一個web網站

1 怎樣的性能測試結果才是有效的
1.1 錯誤觀點
性能測試工具運行一定用戶數都成功，則表示該伺服器能支持這么多用戶數。這是錯誤的。
解答：
A.
因為一次有效的測試結果，不只用戶都運行成功，同時需要保證訪問一個頁面或一次交易的響應時間在合理范圍。「2-5-8原則」，簡單說，就是當用戶訪問一
個頁面或一次交易能夠在2秒以內得到響應時，會感覺系統的響應很快；當用戶在2-5秒之間得到響應時，會感覺系統的響應速度還可以；當用戶在5-8秒以內
得到響應時，會感覺系統的響應速度很慢，但是還可以接受；而當用戶在超過8秒後仍然無法得到響應時，會感覺系統糟透了，或者認為
系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。
B. 測試場景不一定模擬了真實業務場景，因為瀏覽器是並發多線程多TCP完成一個頁面的，而測試工具基本都是1，2個線程；對伺服器的壓力是不一樣的，真實環境的TCP壓力是性能測試工具虛擬環境的幾倍。

2 影響WEB伺服器性能指標的因素有哪些
為什麼性能測試工具，需要提供事務（頁面或交易、全腳本）指標、TCP連接、吞吐量、伺服器資源監控、請求數/響應數。
1) 硬體資源：如CPU、內存、網卡吞吐量、I/O能力、SWAP交換能力
2) 線程數：這里介紹java的WEB伺服器，默認每線程佔用的內存為2M，而32為系統JAVA進程（如tomcat、JBoss）佔得空間只有2G（一般比這個小），因此線程數有限制；64為無限制線程，但CPU要跟得上
3) TCP連接數：操作系統的TCP連接數理論值一般很大，操作系統對TCP連接設置有默認值（怎麼配置，可以網上搜索，這里不介紹）；但實際測試中TCP連接在幾百，就出現測試的響應時間很長。抓包分析，原來是三次握手的SYN包伺服器不及時響應，導致SYN重傳（3秒後，9秒後）。

如果SYN丟了，則會重發，但是第一次是3秒後，第2次是在9秒後，如果重發才收到的SYN_ACK，則導致TCP連接超長，從而導致業務響應時間延長。

4) 響應時間：伺服器響應時間小，用戶體驗才好，在大量用戶並發的情況下，HTTP響應時間在用戶忍受度下才是有效的，一般採用「2-5-8原則」。
5) 軟體本身代碼性能演算法：這個不做介紹，如差的演算法、查詢資料庫時間長等等。

3 測試人員經常遇到的一些常見問題及解答
3.1 為什麼使用瀏覽器訪問頁面響應很快，1-2秒就完成；而使用測試工具卻需要10幾秒，甚至幾十秒才完成腳本
解答：
A.
這是由於瀏覽器訪問頁面響應是並發的，同時並發多個線程（多個Socket），而性能測試工具基本是串列發送請求的。如果一個頁面有100個資源
（CSS、HTML、JS、圖片），需要發送100個HTTP請求，如果使用6個線程（瀏覽器），則每個大概請求14個HTTP；如果使用一個線程（測試
工具），則需要請求100個，時間當然大很多。下圖為chrome瀏覽器調試工具顯示的並發情況：

B. 另外瀏覽器具有緩存功能，如果之前訪問了www.qq.com，
會把一些圖片緩存在瀏覽器臨時目錄，下次請求時發送的HTTP請求會帶上If-Match或Etag等頭域，WEB伺服器判斷資源沒改變則會304響應，
而不是回200 OK，這樣減少資源的傳輸，所以時間就小。而有些測試工具是不攜帶這些頭域（包括Loadrunner），因此回的響應是200 OK。所以測試人員默認真實測試時，可以考慮部分有緩存，部分沒緩存。

3.2 性能測試工具是怎麼模擬WEB虛擬用戶
A. 錄制
使用瀏覽器進行正常業務操作，性能測試工具錄制下HTTP請求信息。一般需要記錄URL與頭域、內容、響應碼。雖然不同的性能測試工具錄制方式不一樣（如
loadrunner採用Hook，JMeter採用代理或badbody，kylinPET採用網卡抓包與代理），但都能實現錄制正常業務的HTTP請
求。
測試工具最好能錄制出緩存頭域，即If-Match或Etag，loadrunner好像不支持錄制緩存頭域。
B. 模擬用戶
根據錄制的腳本發送HTTP請求與接收響應，發送前替換參數（實現多用戶不同參數值）、接收時關聯參數（從接收的響應消息獲取參數值，如Cookie、JSessionID）
下面簡單列舉使用過的性能測試工具是如何模擬的（工具運行一個用戶，然後使用wireshark抓包分析得到的結論）：
 Loadrunner：根據錄制腳本發送HTTP請求，如果HTTP請求包括內嵌資源（如圖片、CSS、JS），會啟動第二個線程執行內嵌資源，即Loadrunner支持同時兩個線程兩個TCP連接。
 kylinPET（國產）：可通過配置設置一個線程或者多個線程並發發送HTTP請求，多個線程並發及TCP連接數跟瀏覽器行為一樣。
 JMeter：只有一個線程，一個TCP連接
 其他工具：本人沒用過，請用過的兄弟姐妹可以補充下。通過wireshark抓包分析。

3.3 怎樣才能測試出WEB伺服器能支持多少真實用戶，怎樣的伺服器調優參數才合理
解答：
這需要性能測試工具可以模擬出真實用戶的行為，包括HTTP請求數、每用戶並發線程與TCP連接數、思考時間、有無緩存。
為什麼需要模擬真實用戶的線程數與TCP連接數呢，上面提到過，WEB伺服器的線程數與TCP連接數往往很低，這不是提高硬體就能輕松解決的，這也是伺服器調優比較復雜的配置。
因此，只有盡最大能力模擬真實用戶（瀏覽器或其它WEB客戶端，可能不同瀏覽器的並發線程與TCP數都不一樣）的行為的測試場景，測試結果才最真實，伺服器調優才最有意義。

4 怎樣才能測試系統支持多少用戶
4.1 模擬真實用戶的行為
只有模擬用戶一樣的行為才可以系統支持的測試用戶數有效，因此需要模擬一樣的並發數、TCP連接數、甚至可以是HTTP請求的時間間隔。用戶可以是瀏覽器、智能手機、智能機頂盒，測試工具模擬他們一樣的行為才是最有效的測試。

4.2 測試結果數據在合理范圍
4.2.1 用戶統計
成功數、失敗數、每秒在線數、最大在線數，通過這些指標分析此次測試結果支持的用戶數、用戶最大數

4.2.2 點擊率
每秒平均HTTP請求數、響應數。分析系統的處理能力

4.2.3 事務
事務成功、失敗、時間，事務一般是整個腳本運行時間、或者一個頁面或一個交易，通過結果分析，得出每個事物的時間是否合理，符合「2-5-8」原則，如果
測試結果顯示事物時間非常大，則表示系統支持不了此次測試的用戶，因為用戶的響應時間太大（像火車訂票一樣，太多用戶導致響應時間長，用戶無法忍受，則認
為這個系統爛）。
當然，還需要查看事務的百分比，分析90%、80%、70%、60%的事務時間是否在合理范圍。

4.2.4 TCP連接信息
TCP連接成功數、失敗數、TCP三次握手時間。因為此次測試結果可能是由於伺服器系統或網路的TCP的丟包與重傳才導致延時大的。如果是伺服器的原因，伺服器收到TCP的SYN而不處理，可以通過調試伺服器的TCP配置來優化。
怎麼才知道是伺服器的問題呢，這個需要性能測試工具能給出TCP連接時間（當前了解只有kylinPET可以支持），如果顯示超過3秒，這時需要檢查是網
絡還是伺服器問題，可以在伺服器端抓包（tcpmp或wireshark）然後分析TCP的SYN信息（個數、時間）

4.2.5 資源佔用
伺服器的CPU、內存、帶寬、I/O是不是已經不足，導致系統上不去是哪個原因，根據原因進行調優或升級。
測試時需要考慮性能測試工具的CPU佔用率，如果性能測試工具佔用CPU很高，此次測試可能瓶頸是在工具，而導致測試結果是無效的。

『貳』 伺服器，可以ping通 但是無法訪問WEB

訪問Web伺服器是許多區域網用戶經常要做的一項「功課」，在頻繁訪問過程中，不少朋友積累了一些Web伺服器訪問經驗，這些經驗常常會幫助他們快速解決一些無法訪問的小故障。不過，本文下面貢獻出來的Web伺服器不能訪問故障現象卻比較特別，如果不加細細分析，單純以經驗來解決故障時，多半容易走彎路；為了幫助各位朋友高效訪問Web伺服器，筆者現在就將這種特別的網路訪問故障排除過程還原出來，希望大家能從中收到啟發！

能Ping通但是不能訪問

某單位區域網規模不大，總共18台普通計算機，外加一台安裝了Windows Server 2003系統的Web伺服器，所有普通計算機以及Web伺服器全部連接到一台可管理的核心交換機中，並通過寬頻路由器實現區域網共享上網。平時，18台普通計算機中安裝使用的操作系統不盡相同，有使用Windows XP系統的，有安裝Windows Vista系統的，也有兩台計算機比較破舊仍然還在使用Windows 98系統，不過這些計算機都能正常訪問區域網中的Web伺服器。

可是，最近一段時間，區域網用戶通過IE瀏覽器訪問Web伺服器站點內容時，系統屏幕上竟然出現了身份驗證對話框，要求用戶輸入合適的用戶名和密碼信息；事實上Web伺服器根本沒有啟用身份驗證功能，它平時能允許區域網中的任何用戶通過匿名身份登錄、訪問其中的站點內容，那為什麼現在會出現這種現象呢？更讓人感到奇怪的是，網路管理員無論輸入Web伺服器的合法用戶賬號還是輸入超級管理員賬號，都無法順利通過Web伺服器的身份驗證，這是什麼原因呢？網路管理員嘗試使用Ping命令來測試區域網目標Web伺服器的連通性時，發現Web伺服器能夠被正常Ping通，這也證明區域網普通計算機到Web伺服器之間的物理連接線路是正常的；在線路通暢的情況下，遇到Web伺服器訪問不正常的故障現象，這很可能是Web伺服器自身哪裡出現了問題。

檢查Web站點訪問許可權

起初，網路管理員還以為是Web伺服器自身設置不當，造成了區域網用戶不能正常訪問。考慮到Web伺服器突然要求進行身份驗證，網路管理員判斷這肯定是Web伺服器的訪問許可權被意外修改了，於是立即進入Windows Server 2003伺服器系統，依次單擊「開始」/「設置」/「控制面板」，雙擊控制面板中的「管理工具」圖標，再雙擊其中的IIS控制圖標，打開對應系統的IIS控制台窗口，從中找到目標Web伺服器對應的站點名稱，然後用滑鼠右鍵單擊目標站點名稱，執行右鍵菜單中的「屬性」命令打開目標站點的屬性設置窗口；單擊該設置窗口中的「目錄安全性」選項卡，在對應選項設置頁面的「身份驗證和訪問控制」處單擊「編輯」按鈕，打開如圖1所示的設置對話框，在這里網路管理員無論是選中還是取消選中「匿名訪問」、「集成Windows驗證」等選項，Web伺服器依然還要進行身份驗證，這說明這種故障現象與目標Web伺服器的訪問許可權設置無關。

檢查伺服器連接限制

由於輸入了合法用戶賬號、甚至超級管理員賬號也不能正確登錄進Web伺服器，網路管理員開始懷疑起Windows Server 2003伺服器系統可能對用戶的同時連接數量進行了限制，因為一旦對Web伺服器的站點主目錄用戶連接數量進行限制時，延後登錄的用戶是無論如何也不會訪問到Web伺服器中的站點內容的。想到這一點，網路管理員先是打開伺服器系統的資源管理器窗口，從中找到Web伺服器的站點主目錄，並用滑鼠右鍵單擊該目錄圖標，執行快捷菜單中的「屬性」命令，打開目標站點主目錄的屬性設置窗口；單擊該設置窗口中的「共享」選項卡，在對應的選項設置頁面中，網路管理員果然發現Windows Server 2003伺服器系統將該目錄的用戶訪問數量限制為了5，於是嘗試將該參數修改成20，同時保存好該設置操作，之後再次訪問Web伺服器時，仍然出現了相同的故障現象。

後來，網路管理員上網查詢了用戶連接限制方面的信息時，發現Windows Server 2003伺服器系統要是授權模式設置不當時，也會出現用戶連接數量受到限制的現象。搜索到這樣的結果，網路管理員心中暗自興奮了一下，看來Web伺服器不能訪問的故障現象馬上就能解決了；他立即打開Windows Server 2003伺服器系統的「開始」菜單，從中依次點選「設置」/「控制面板」命令，並雙擊其中的「授權」選項，在其後的界面中網路管理員發現伺服器系統在默認狀態下選用了「每伺服器」選項，同時看到用戶連接數量顯示為「5」，很明顯這里的參數沒有設置正確。網路管理員立即選用了這里的「每設備或用戶」選項（如圖2所示），之後在每設備或每客戶授權對話框中選中了「我同意」選項，最後重新啟動了一下伺服器系統；原以為這樣的努力肯定會有收獲，可是重新從普通計算機中訪問區域網Web伺服器時，系統屏幕上還是出現了讓人討厭的身份驗證對話框。

意外找到故障原因

就在網路管理員毫無頭緒的情況下，某位區域網用戶突然跑來向網路管理員求援，說他們部門為了工作需要，最近新買回來了一台網路列印機，將該網路列印機連接到單位的核心交換機中，並設置好相關的網路列印參數後，他們部門的所有用戶都能正常使用網路列印機列印材料了，不過在今天，他自己的計算機卻不能使用網路列印機了，而其他人卻能正常進行網路列印。聽到這位用戶的求援，網路管理員立即來到了網路列印機現場，登錄到列印機後台管理界面，偶然之間打開了網路列印機的日誌頁面，發現網路列印機的IP地址與區域網中某台計算機IP地址發生了沖突，再仔細檢查那個發生沖突的IP地址時，竟然是Web伺服器使用的IP地址，怪不得Web伺服器不能正常訪問，原來網路列印機的IP地址與它使用的IP地址發生意外沖突了。

原來，為了管理和維護方便，網路列印機上也運行著一個Web服務，用戶通過Web形式的後台管理界面，可以非常輕松地設置網路列印機的各種上網參數，不過網路列印機自帶的Weh伺服器在默認狀態下不支持匿名訪問。當用戶為網路列印機設置的IP地址與Web伺服器地址發生沖突時，區域網用戶再在IE瀏覽器窗口的地址欄中輸入Web伺服器的IP地址時，其實訪問的是網路列印機的後台登錄界面，這也是為什麼訪問Web伺服器時系統屏幕上出現身份驗證對話框的原因。此時，使用Ping命令測試Web伺服器的連通性時，卻測試到了網路列印機身上，那樣一來網路列印機可以被Ping通，但需要輸入合法的用戶賬號才能訪問。

弄清楚了故障原因後，網路管理員立即修改了網路列印機的IP地址，保證了Web伺服器的IP地址沒有與其他計算機的IP地址發生沖突，結果再次訪問Web伺服器時，果然能夠很快速地打開其中的頁面內容了，至此Web伺服器能Ping通但不能訪問的故障現象就被成功解決了。

最後的總結

這種網路故障解決起來其實並不十分復雜，順藤摸瓜一定能夠找到最終的故障原因。不過，該故障從另一個角度提醒我們每一位網路管理員，解決網路故障不能盲目地套用經驗，而應該先在解決故障之前熟悉網路環境的最新變化，熟悉工作環境中的各種網路設備的功能特性，只有知道了網路的最新變化以及網路設備的各種特性，我們才會在遇到網路故障的時候，下意識地進行思考與聯想，只有這樣才能迅速地找到具體的故障原因，並且能夠及時地採取措施來快速解決網路故障。

『叄』 一個web伺服器能承受多少訪問量

沒有固定，需要看伺服器配置高低。

不僅僅是訪問量問題，主要是數據，如果站點數據量不是太大。沒有太多的查詢。一台P4的普通電腦可以承受成千上萬的上網用戶。（還有帶寬問題，比如共享的100兆位。高帶寬。在線人數更多）

如果您有一個幾百兆位元組或幾十億位元組的資料庫。這是另一回事。伺服器的內存必須至少是資料庫的3倍才能運行。

無論如何。常見的企業網站。幾百米的股票。P4的平台。網上幾千個就足夠了（沒有下載，沒有視頻）。

(3)如何判斷web伺服器支持用戶在線擴展閱讀：

WEB伺服器類型：

1，IIS

IIS伺服器稱為:Internet信息服務。它是微軟公司擁有的web伺服器，是目前最流行的web伺服器產品之一。

2、康樂

Kanglewebserver（Kangle）是一款跨平台、功能強大、安全穩定、易於操作的高性能web伺服器和反向代理伺服器軟體。

3，WebSphere

WebSphereApplicationServer是一個功能齊全的開放Web應用程序伺服器，它是IBM電子商務計劃的核心部分。它是一個基於java的應用程序環境，用於構建、部署和管理Internet和IntranetWeb應用程序。

4，WebLogic

BEAWebLogicServer是一個多功能的、基於標準的web應用程序伺服器，為企業構建自己的應用程序提供了堅實的基礎。

5，Apache

Apache是世界上使用最多的Web伺服器，佔有大約60％的市場份額。

6，Tomcat

Tomcat是一個開源的基於java的Web應用程序容器，它運行servlet和JSPWeb應用程序。

7，Jboss

它是一個基於J2EE的開源應用伺服器。JBoss代碼是在LGPL下授權的，可以在任何商業應用程序中免費使用，而不需要支付任何費用。

『肆』 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
這是由微軟的網站測試人員開發的專門用來進行實際網站壓力測試以一套工具。透過這套功能強大的壓力測試工具，管理人員可以在網站實際上線之前先網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調整、設置工作。