给定有关实际站点流量的数据，如何计算负载测试中要使用的虚拟并发用户数？

#1 楼

好吧，所以特里斯坦（Tristann）友善地修改了他最初的问题，以包括有关情景的更多细节。因此，我要添加第二个答案以更直接地解决它。

首先，您可能想问几个有关客户最关心的问题以及他们想要测试的问题，这是一个小样本：


完整的购买对于既定用户来说是什么样的购物时间？
最小，平均，最大
第一次购物者有多少辆完整的购物车
并在结帐时创建了帐户
。 （这平均会增加多少时间？）
放弃购物车的购物者在网站上的平均停留时间是多少？
平均购物车中有多少物品
完全被处理了。
平均每个购物车中有多少商品
被遗弃的购物车。

这些的答案将用来弄清楚您有多少种不同的购物场景需求，以及如何调整思考时间，以及在随机分配思考时间时使用的范围。正如您开始看到的那样，我们至少需要三种情况，即首次购物者，返回购物者，废弃购物车。然后，您将了解需要为每种情况等搜索并放入购物车中的商品的数量。

让我们回答一些问题，并集中于返回购物者的情况。在“高峰时间”测试中。我们假设平均时间是10分钟，最低5分钟，最高15分钟，而3/4的用户是回头用户。

因此，在创建负载测试方案时，您将需要在没有思考时间的情况下计时，然后在每个步骤中调整合理的思考时间，以使启用思考时间的脚本大约需要10分钟才能完成。运行脚本时，您需要对思考时间设置随机化，以允许规定时间的+/- 50％。

因此，对于高峰时段测试，我们将需要600次“废弃购物车”方案的迭代，100次“新用户”方案（在结帐时注册新用户）和300次迭代的返回用户方案。

因此，对于返回的用户脚本，如果平均需要花费10分钟来运行，则单个vuser在我们的测试期间可以运行该脚本6次。要总共获得300次迭代，我们将需要并行使用50个vuser。在那一小时内（50 * 6 = 300）

如果我们暂时假设废弃的购物车的持续时间为4分钟，则运行该场景的每个vuser可以在运行过程中执行15次迭代（60/4）小时。因此，要在一个小时内运行600个迭代的废弃Scrip的目标，您将需要（600/15）40个vuser在负载测试期间运行该方案。

如果新用户脚本需要平均需要15分钟才能完成，那么您在一小时内每个用户可获得4次迭代，并且您需要25个运行该方案的vuser才能在一小时的时间内获得100次迭代。

所以总结果是40 + 50 + 25或115个vuser来模拟现有的高峰时间。如果要在一个小时内模拟更大的流量爆发，则可以使用更多的vuser，并让loadtest工具将它们先升高然后降低，这样您仍然可以得到迭代，但在测试。

然后（假设您已经创建了很多测试数据），如果客户希望查看站点是否可以承受当前负载的4倍，则可以运行相同的方案，但使用160 + 200 + 100 = 460个vuser，而不是115

#2 楼

我在博客文章中写了有关并发用户和号码的信息：http://blog.xceptance.de/2011/06/07/get-the-right-load-mix-out-of-a-few-numbers/


等一下...我的并发用户在哪里？
这很简单：“并发用户”是
一种不准确的流量描述方式，所以我们没有使用了那个
号码。为什么会这样呢？

为了深入了解这一点，我们
只需检查一次拜访需要多长时间。
根据商店的不同，平均拜访次数可能会需要2到4分钟。
成功购物可能需要15分钟。如果我们希望每次访问大约10页
，并且页面浏览需要
加载1秒，读取20秒（
）（平均而言，这个数字确实很高） ），一次访问
将花费10 * 1秒+ 9 * 20秒=
190秒。

让我们平均用190秒进行一次
访问。如果我们一次只能服务一个访客，那么我们可以服务60分钟（3600秒）/每次访问190
秒=每个小时的19个访客。但是，由于我们希望每小时提供10,000个服务，因此我们必须同时处理10,000 / 19 = 526个访问者
。这是著名的
并发用户数。

如果现在将思考时间加倍，那么我们
有1,052个并发用户/访问者。
如果将其减少到1秒的思考时间
，我们的访问时间为19
秒，因此10,000次访问/
（3600秒/ 19）= 53个并发
访问者。

#3 楼

注意：此答案是针对问题的早期版本的，该问题要求您在vuser之间建立1：1关系，以此类推。与其重新措词，不如说它原样，因为里面的信息仍然很不错。但是现在您知道了为什么它似乎没有直接回答新版本的问题。

通常，如果您负担得起（例如，vuser的许可证，运行vuser的测试装置的硬件），最好的答案是使用1：1关系。这意味着在加载方案的所有步骤之间都要考虑思考时间，并且可能需要大量的vuser。现在，对于某些系统，例如开源或VSTS Ultimate（现在具有无限的vuser许可证），许可vuser的成本并不高，并且由于设计良好的系统可以从单个cpu上运行多达1000个vuser，因此硬件成本

之所以最好，其原因有很多，但最重要的是


它迫使服务器端< br维护和更新每个vuser的并行会话
，因此服务器上的压力
与您可以实现的现实情况
差不多。
如果事务间隔和
认为时间是随机的，您仍然有可能
在给定的较短时间内接近
用户的最大“冲动”或“爆发”
>
如果我们要谈论的是相对较短的时间段（例如1-10秒）还是相对较大的持续时间（例如每小时的用户），则后一点非常重要。如果要压缩思考时间并使用100个vuser重复一个脚本，该脚本需要36秒来模拟一个小时内10000个用户的负载，则在此期间您可以生成的最大“峰值”为100个请求。如果您使用1000个vuser，每个vuser重复执行一个耗时6分钟的脚本，则最大峰值为1000个请求，与实际发生的情况更为接近。

但是请注意，在这种情况下，我不会使用10,000个vuser来表示该小时内站点上的负载。由于测试时间为一小时（可能代表一天中的高峰时间），并且脚本平均只需花费6分钟（包括思考时间）执行，因此我可以重用该vuser来模拟最多10个正常的负载用户在一个小时的持续时间内。 OTOH，如果高峰负载在一个小时内“一次”是2000个用户，那么我想做的是使用2000个vuser，并让他们在脚本迭代之间平均等待6分钟，以便每个脚本执行5次

OTOH，如果您只是试图对浏览静态页面的非登录访客的“后台负载”进行建模，然后精简思考时间并使用单个vuser来模拟在一段时间内来自多个“同时”用户的交易仍然是相当现实的，当每个vuser的成本很高时，可以为您省钱。请注意，这具有创建非常平滑的连续负载的效果，这在现实生活中是不会发生的。印刷版，我非常喜欢它）在性能测试上，它与平台无关，并且非常值得从事性能或负载测试的任何人阅读。您可以从此Codeplex链接获取它

#4 楼

对自己有效的方法，以及我在别人那里教过的方法，是缩小并发用户的总数，并减少思考时间（用户除了阅读外不做任何事情的时间），然后缩小一次用户离开，另一个人到达。它需要一些数学运算和大量故障排除，但是，它已经用于一些基本性能测试。

#5 楼

我已经创建了一个iOS应用，您可以通过它在iPhone / iPad / iPod touch上设置/计算所有性能测试方案。

希望它对性能测试社区有所帮助。 > App Store链接。

支持站点/教程链接。

如果您需要帮助，请在支持站点向我发送电子邮件。