伺服器的並發數與什麼有關

① 並發與迭代

例如在LR里，我要測100個用戶同時並發登陸所用時間，那我是不是在錄制好腳本後，需要參數化「用戶名」，

「密碼」以及在那個記事本里構造100個真實的用戶名和密碼？ 然後運行Controller，

設置用戶數為100？那麼這里的迭代次數該怎麼設啊，設成1和設成10有什麼區別啊？

我老是搞不清測試並發用戶，「迭代」和「並發用戶數」（就是controller里設的虛擬用戶數）的區別。

ZEE的回答：

用比喻的方式來回一下：

四車道的馬路，如果只有四輛車並排走過就是並發；

              如果四輛車排成一縱隊走過就是迭代；

              如果有100輛車排成25行依次走過就是並發加迭代。

在以上說法中，只有並排的車是我們設置的用戶數。

通過用lr做負載壓力測試過程發現，如果設定不同的action迭代次數，每次得出的結果是不同的，曲線的表現形式也是不同的。

這點就使我們會感覺困惑,為什麼要設置action的迭代次數？以及對於不同的應用系統應該怎樣設置迭代次數呢？

首先你要理解性能測試是在干什麼？

性能測試是模擬系統一段時間內真實的壓力情況，以考察系統的性能。

再看怎麼模擬系統真實的壓力情況？比如在半個小時內，用戶都在進行登錄操作，且平均分布在這半個小時內。我們要做的是什麼？

模擬這半個小時用戶的行為。怎麼模擬？估算出同時操作的人數，並用LoadRunner不斷的發送登錄請求，這就是我們為什麼要迭代。

至於迭代次數，只要能夠模擬出真實情況，多少次都無所謂，不過10次8次估計是模擬不出來。

迭代次數至少要保證壓力達到一個穩定值後再運行一段時間，這樣我們得到的數據才是有效的。

所以我們除非是特別要求，一般不用迭代次數，而是用運行時間。

1，迭代和並發，是完全不同的概念。沒有什麼關系。

比如，一個用戶迭代十次，還是一個用戶的壓力。

10個用戶執行一次，就是10個用戶的壓力。10個用戶迭代10次，還是10個用戶的壓力。但他們都和參數化的數據有關系

（也要看參數化是如何設置的，以及系統如何判斷提交值的）。

2,你要是想知道，LR是如何實現迭代和並發：

說一個比較容易理解的層面：迭代就是不停的反復調用同一腳本，反復執行，注意，

對1個用戶執行10次來說，只會分配一塊內存。

10個用戶執行一次，是調用同一腳本10次，會分配10塊內存。

LR調用腳本，編譯後，運行，按腳本發送數據。

比如：web_url這樣的函數，執行就會發HTTP request。

如果你還想知道更細節的進程和函數的實現，只能側面驗證（具體方法看各人的能力和擅長），因為我們都不是LR的開發者。

3,太顯然的問題了，參數化時選擇每次出現唯一，只要參數夠用就OK，不夠用，就設置相應的規則。

action在場景運行中iteration只對其起作用，對vuser_init和vuser_end都不起作用，

action是一個可以被重復使用的最小單位其實你可以將所有腳本錄制到一個action里，只是不方便管理罷了。

舉個最簡單的例子，

像lr自帶的例子——訂票系統，你如果把所有腳本都錄制到一個action里，

那回放的時候，每個用戶登錄就只能買一張票，而如果想一個用戶買多張票的話，這樣就行不通了。

那你就要設多個action，並把登錄和結束各錄制在一個action里，把買票錄到一個action中，

這樣，將買票的action迭代多次，而用戶登錄和結束只運行一次，這不就模擬了現實中的情況了嗎？

其實LoadRunner 是以客戶端的角度來定義「響應時間」的，

當客戶端請求發出去後， LoadRunner 就開始計算響應時間，一直到它收到伺服器端的響應。

這個時候問題就產生了：如果此時的伺服器端的排隊隊列已滿，伺服器資源正處於忙碌的狀態，

那麼該請求會駐留在伺服器的線程中，換句話說，這個新產生的請求並不會對伺服器端產生真正的負載，

但很遺憾的是，該請求的計時器已經啟動了，因此我們很容易就可以預見到，

這個請求的響應時間會變得很長，

甚至可能長到使得該請求由於超時而失敗。

等到測試結束後，

我們查看一下結果，就會發現這樣一個很不幸的現象：

事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，

而這個時候的平均響應時間，其實也就失去了它應有的意義。

也就是說，由於客戶端發送的請求太快而導致影響了實際的測量結果，

設置步長則可以緩解這一情況，這樣，應該試試設置pacing，再運行看看情況。

並發用戶數量，有兩種常見的錯誤觀點。

一種錯誤觀點是把並發用戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；

還有一種比較接近正確的觀點是把用戶在線數量理解為並發用戶數量。

實際上，在線用戶不一定會和其他用戶發生並發，例如正在瀏覽網頁的用戶，對伺服器是沒有任何影響的。

但是，用戶在線數量是統計並發用戶數量的主要依據之一。

並發主要是針對伺服器而言，是否並發的關鍵是看用戶操作是否對伺服器產生了影響。

因此，並發用戶數量的正確理解為：在同一時刻與伺服器進行了交互的在線用戶數量。

這些用戶的最大特徵是和伺服器產生了交互，這種交互既可以是單向的傳輸數據，也可以是雙向的傳送數據。

比如說：有一個這樣的場景，系統在線用戶是100個，但是同時操作某一個事物（比如說登陸操作）的人是20個那麼場景怎麼設計了？

在Controller中設置100個虛擬用戶執行這個腳本，然後登陸操作之前放一個集合點，然後設置集合點的策略（20個用戶到達時即執行集合點）

對於多個業務場景, 只要錄制多個腳本放在同一個場景內, 然後分配不同比例的虛擬用戶就可以了,

如果不想跑哪個業務場景, 那就不選中這個腳本即可.

追問

並發用戶數，我可不可以在採集的時候理解為最大的允許vuser值

回答

某個腳本設置的vuser值, 可以理解為這個業務場景的並發用戶數,但如果要測試具體某個業務的並發操作,  那就需要設置集合點,

而且集合點數目不能大於vuser值.

LoadRunner是怎麼重復迭代和怎麼增加並發運行的呢？

另外，在參數化時，對於一次壓力測試中均只能用一次的資源應該怎麼參數化呢？就是說這些資源用了一次就不能在用了的。

－－參數化時,在select  next row選擇unique,update value on選擇 each occurence,

1. 迭代跟虛擬用戶數沒什麼必然聯系

迭代是這樣的：

迭代1次  迭代2次  迭代3次

用戶1    X1          X2            X3

用戶2    Y1          Y2            Y3

其中的X1-3 Y1-3是參數，參數規則就是二樓說的

這么兩個用戶是根據你的rump up 上來的，比如5秒上兩個用戶，那麼用戶1和2就在5秒之內載入進來的，不知道說清楚了沒。

第二個問題就簡單了，只能用一次的參數，首先確保你的參數足夠，另外規則選擇的時候，注意選擇唯一

迭代次數只是對你設置了迭代次數的action進行迭代，而用戶數可以理解為對整個錄制過程的迭代（只是各個用戶不同）

    而且增加並發量可以通過增加用戶來達到還可以設置集合點來增加某個操作的並發量

假如一個腳本，設置最大並發量為10，每5秒中增加2個並發用戶，而Action設置的迭代為10次：

當開始至2秒時，載入了2個用戶，這2個用戶分別開始運行，並都運行10次，不管這個2個用戶運行10次是否結束，當下一個2兩秒到來時，

    即開始至第4秒時又載入了2個用戶，這2個又運行10次；就這樣一直載入到10個並發用戶，然後當每個用戶都運行完10次時就結束。

這樣中間最大並發是10個，但不一定能達到10個，因為在載入最後幾個時，前面的有可能已經運行結束，

    所以如果要真正達到最大並發10就必須設置集合點來完成

不過也不一定非要設置集合點才能實現同時處在running的狀態有10個用戶。

設置ration也是可以的。不過那就不只每個用戶運行10次了。

如果想實現用戶迭代10次，並且想同時running為10個用戶，就應該設置集合點。

迭代（Iterate）設計，或者我們稱之為增量（Incremental）設計的思想和XP提倡的Evolutionary Design有異曲同工之妙。

② 伺服器 並發連接數取決於什麼

一台伺服器的並發數是一定的

③ 並發數與伺服器配置的關系，能舉個例子說明一下嗎

做網站的話，伺服器要分前端和後端的，還有cache、負載平衡、網路帶寬和存儲系統等問題要考慮，不是單講一台伺服器就能說清楚的。

只討論一台伺服器的話，3650雙路加4G內存支持到5萬並發是容易達到的，即使針對業務流比較復雜的情況，也能滿足很大程度的需要。
但是考慮到存儲子系統，比如4塊sas硬碟raid0，可能只能達到5000數量級的並發請求。如果是以另外的光纖盤陣來支持存儲則可以顯著提高硬碟傳輸帶寬的性能。
最後還要考慮到你的網路帶寬，對大多數網站來說，通常這才是最大的瓶頸所在。也就是說即使你的cpu、內存、硬碟都沒問題，也會因為租用的網路帶寬限制而影響最大的並發數。

還有一點，經過優化的網站程序對結果也有很大影響。事實上很多網站的訪問體驗很糟糕，其實不是因為硬體的原因，而是程序寫的太爛。

很抱歉我本想以單台伺服器來講，但是說著說著又變成講網站架構了。不如舉個例子吧，如果你在這台伺服器上運行discuz或動網之類的服務，在沒有特別高峰的情況下，5萬並發是沒有問題的。

④ 請教伺服器並發數與cpu主頻的關系

二者之間好像沒什麼關系。
要看你的每個連接平均需要多少資源。
比如ftp服務，並發數多了硬碟和網卡可能支撐不住；資料庫服務如果每個查詢都很復雜，消耗cpu就大；web頁面如果伺服器端腳本比較多，對資源消耗肯定比靜態頁面高。
具體問題具體分析，單純比較並發數和cpu，意義不大。

⑤ 並發數是什麼意思

並發數
並發數，計算機網路術語，是指同時訪問伺服器站點的鏈接數。

由於虛擬主機是建立在每台伺服器多用戶的基礎上的，也就是多個用戶共同使用一台伺服器。為了避免同一台伺服器上的某一個用戶的IIS鏈接人數過多或佔用伺服器資源過多而影響其它用戶的正常使用，所以，目前所有虛擬空間提供商都對單個用戶的IIS鏈接數，流量及伺服器進程佔用CPU的比率進行了相應的限制。 當某一個用戶的站點超出了伺服器上的設制後，訪問站點時就會出現伺服器忙，或目前訪問該站點的人數過多，超出了WEB的處理能力等相關錯誤提示。

⑥ 什麼是並發數

並發數，計算機網路術語，是指同時訪問伺服器站點的連接數。

由於虛擬主機是建立在每台伺服器多用戶的基礎上的，也就是多個用戶共同使用一台伺服器。為了避免同一台伺服器上的某一個用戶的IIS鏈接人數過多或佔用伺服器資源過多而影響其它用戶的正常使用。

所以，目前所有虛擬空間提供商都對單個用戶的IIS鏈接數，流量及伺服器進程佔用CPU的比率進行了相應的限制。 當某一個用戶的站點超出了伺服器上的設制後，訪問站點時就會出現伺服器忙，或目前訪問該站點的人數過多，超出了WEB的處理能力等相關錯誤提示。

(6)伺服器的並發數與什麼有關擴展閱讀：

並發連接數是衡量防火牆性能的一個重要指標。在市面上常見防火牆設備的說明書中大家可以看到，從低端設備的500、1000個並發連接，一直到高端設備的數萬、數十萬並發連接，存在著好幾個數量級的差異。

在我們用電腦工作時，打開的一個窗口或一個Web頁面，我們也可以把它叫做一個「會話」，擴展到一個區域網裡面，所有用戶要通過防火牆上網，要打開很多個窗口或Web頁面發（即會話），那麼，這個防火牆，所能處理的最大會話數量，就是「並發連接數」。

檢查您的網站是否存在比較大的圖片、FLASH、音樂、電影等文件，例如：某一個站點的訪問用戶並不是很多，IIS鏈接數也可能只有幾十個，但是他在網頁中使用了比較大的的FLASH或圖片（如超過300K），以增強網頁效果。

結果就可能會出現不能訪問的情況，原因是該站點的流量（帶寬）使用量超限，所以建議網頁上盡量使用較小的文件，這樣即能避免流量超限，也能增加客戶端的下載速度，給客戶更好的感覺！

最後請注意：伺服器對於某一個鏈接的默認超時時間一般為15--20分鍾，也就是當訪問用戶訪問你的網頁並關閉後，一般需要15--20分鍾，伺服器才從其內存中將其清除，視為無效鏈接！

⑦ 並發數與伺服器配置的關系，能舉個例子說明一下嗎

並發數是說同一時刻, 有多少人訪問你的伺服器, 注意不是同一秒, 是同一時刻, 伺服器的配置當然就要看你處理一個請求所花費的時間, 例如一個請求, 你要花費1000毫秒(1秒鍾) 那你可以在伺服器做並發測試, 看看並發的時候, 性能達到多少

⑧ 一台應用伺服器怎麼計算其並發量

並發的意思是指網站在同一時間訪問的人數，人數越大，瞬間帶寬要求更高。伺服器並發量分為：1.業務並發用戶數；2.最大並發訪問數；3.系統用戶數；4.同時在線用戶數；
說明伺服器實際壓力，能承受的最大並發訪問數，既取決於業務並發用戶數，還取決於用戶的業務場景，這些可以通過對伺服器日誌的分析得到。

一般只需要分析出典型業務（用戶常用，最關注的業務操作）

給出一個估算業務並發用戶數的公式（測試人員一般只關心業務並發用戶數）

C=nL/T

C^=C+3×(C的平方根)

C是平均的業務並發用戶數、n是login session的數量、L是login session的平均長度、T是指考察的時間段長度、C^是指業務並發用戶數的峰值。

假設OA系統有1000用戶，每天400個用戶發訪問，每個登錄到退出平均時間2小時，在1天時間內用戶只在8小時內使用該系統。

C=400×2/8=100

C^=100+3×(100的平方根)=100+3×10=130

另外，如果知道平均每個用戶發出的請求數u，則系統吞吐量可以估算為u×C

精確估算，還要考慮用戶業務操作存在一定的時間集中性（比如上班後1小時內是OA系統高峰期），採用公式計算仍然會存在偏差。

285-104-1346

⑨ 影響web伺服器請求並發數量的因素

影響web伺服器請求並發數量的因素
只討論一台伺服器的話，3650雙路加4G內存支持到5萬並發是容易達到的，即使針對業務流比較復雜的情況，也能滿足很大程度的需要。
但是考慮到存儲子系統，比如4塊sas硬碟raid0，可能只能達到5000數量級的並發請求。如果是以另外的光纖盤陣來支持存儲則可以顯著提高硬碟傳輸帶寬的性能。
最後還要考慮到你的網路帶寬，對大多數網站來說，通常這才是最大的瓶頸所在。也就是說即使你的cpu、內存、硬碟都沒問題，也會因為租用的網路帶寬限制而影響最大的並發數。