我針對單個url（OpenAM isAlive.jsp站點）運行LoadRunner http協議請求，並使用100 VUsrs（http）獲得大約1000/900次/秒的吞吐量。Loadrunner TruClient和足夠的吞吐量/httsPerSeconds
與TruClient運行類似的測試中，我嘗試運行100個VUseres，當我達到約40 truclient Vuser的吞吐量實際上減少了一些請求失敗和吞吐量戈德斯下降至0（！）
是TruClient明智失敗的交易和/或錯過的要求？就好像有些人失敗了會毀了整個測試？
我想對我的SUT產生足夠的負載。
任何thougts？
它不是負載生成器，也不是被測系統（SUT）。
任何commmets將不勝感激！
BR 馬格努斯Fuglerud
你的問題是在負載生成器。 Truclient協議實際上在負載生成器機器上打開了一個REAL瀏覽器。 在同一臺計算機上打開40個用戶時，會導致RAM和CPU問題，導致瀏覽器運行緩慢並卡住。
你應該準備一個海量負載測試機陣列，用於運行40個用戶我會說你至少需要4臺電腦。
當試圖產生大量負載時，這不是最有效的協議。如果可能的話，我會使用AJAX或HTTP。
Koby。
我的假設是，你有一個單一的飽和負載發生器，當你從40個用戶轉移到100個用戶時，這個負載發生器幾乎爲零。這種虛擬用戶類型的重要性在於，爲什麼我回避它的普遍使用，並將其歸咎於少數甚至更少的地方，因爲那些不瞭解性能測試重點的人提出某種「渲染」需求。
看看你的測試牀。最起碼你應該在你的測試牀上至少有三個負載發生器，硬件匹配。兩個用於主要負載，一個用於控制集。這與控制器無關。在控制生成器上的兩個「主要負載」生成器和每個業務功能類型的一個虛擬用戶上運行大部分負載。在測試過程中觀察您的交易響應時間
如果您看到您的控制組的交易響應時間開始與全局組有所不同，那麼您有問題。全球變得越來越平均，而控制組以相同速度持續或變快，這是負載發生器故障的絕對標誌，獨立於工具並且獨立於測試所使用的協議。
也考慮轉移到一個模型，其中大部分負載是http，並且只有少數是Truclient，它們在哪裏運行以滿足無法以其他方式滿足的需求。可能存在需要更高層開發方法的技術環境，但這些技術環境很少，尤其是當您移除對性能測試中不包含的第三方服務的呼叫時。