我是如何确定并发用户数的！

sybilnana

<P>3.1 在线用户这个用户数，在项目没有上线的时候，是根据项目的愿景来的。</P>
<P>《项目需求调研表》可以帮助你确定下用户数量。</P>
<P>&nbsp;在线用户数： </P>
<P>C=nL / T 其中C是平均的在线用户数，n是平均每天访问用户数，</P>
<P>L是一天内用户从登录到退出的平均时间（操作平均时间），</P>
<P>T是考察时间长度（一天内多长时间有用户使用系统）。</P>
<P>&nbsp;</P>
<P>在线用户数峰值计算： </P>
<P>C^ 约等于 C + 3*根号C ，</P>
<P>其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。</P>
<P>&nbsp;</P>
<P>举个例子： GWD系统，愿景用户数为10000人。</P>
<P>10000人中有5000销售人员，5000普通用户。销售人员，平均每天在线4小时，普通人员在线2小时。</P>
<P>系统中在线人数 = 5000*4/8+5000*2/8 = 3750 3750不是我们要测的在线人数。峰值人数才是我们要测的。</P>
<P>&nbsp;</P>
<P>峰值人数 = 3750+3*根号3750 = 3950</P>
<P>&nbsp;</P>
<P>&nbsp;还有一种说法是峰值人数是普通在线人数的3倍。3750*3 &gt;10000了。在我们的OA系统中不现实。</P>
<P>&nbsp;</P>
<P>想要把在线用户数统计的比较准确，还是需要大量的统计工作。</P>
<P>对系统中各种角色的在线时间，做一个比较完整的统计（在系统试用时，跟试用用户做下统计）。</P>
<P>这样的数据更有说服力。</P>
<P>&nbsp;</P>
<P>&nbsp;3.2 并发用户 </P>
<P>&nbsp;</P>
<P>网上关于并发用户的说辞也是比较多的。</P>
<P>有一种说法是：并发用户是在线人数的10%-20% 也没有什么理论依据。</P>
<P>可能是前人总结，统计的结果。我们没有采纳。</P>
<P>&nbsp;下面是我们讨论的结果： 我们决定使用在线用户数，作为并发用户数。</P>
<P>&nbsp;</P>
<P>并发多少用户其实并不重要，关键是我们是否能通过并发用户，模拟我们想要服务器承受的压力。</P>
<P>&nbsp;</P>
<P>在前面提到过“虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一”。</P>
<P>&nbsp;</P>
<P>这里我们就通过控制思考时间的长短，来调整我们想要的压力。</P>
<P>&nbsp;</P>
<P>还是使用上面的例子，经过统计 销售人员一天工作量：新增30个客户，新增30个交往，新增30个预约，查询30次。</P>
<P>新增客户与服务器交互2次。</P>
<P>新增交往与服务器交互2次。</P>
<P>新增预约与服务器交互2次。</P>
<P>查询与服务器交互1次。</P>
<P>一个销售人员每天与服务器交互的次数为 30*2+30*2+30*2+30 = 210 </P>
<P>&nbsp;</P>
<P>一个普通人员一天与服务器交互的次数为 60次 </P>
<P>&nbsp;</P>
<P>每天服务器处理交互的次数为：210*5000+60*5000 = 1350000 </P>
<P>&nbsp;</P>
<P>每天正常8小时中，平均每秒处理的交互次数为：1350000/(8*3600) = 47 </P>
<P>&nbsp;</P>
<P>这里的交互指的是：每次引起页面内容变化的操作。每个事务的交互次数，自己执行一遍，统计一下就能得到。 </P>
<P>&nbsp;</P>
<P>上面我们得到的虚拟用户数为3950，我们并发3950个虚拟用户，为了达到想要的压力，</P>
<P>我们把每步操作之前的思考时间设置为 （ 0—3950/47）之间的随即数。</P>
<P>这样就能达到服务器每秒处理47次请求的压力。可以根据实际情况调整思考时间，改变压力。</P>
<P>&nbsp;</P>
<P>服务器交互的次数的估计，也需要一个比较详细的调查统计。</P>
<P>需要对使用系统的各类角色的工作量做一个大概的统计。然后才能做出跟接近真实压力的模拟。</P>

[ 本帖最后由 sybilnana 于 2008-10-16 09:07 编辑 ]

zhuyuancan

沙发！！！就希望看到多一点这样的帖子！！！谢楼主分享！！！！但是对于只有把思考时间设定为：”每步操作之前的思考时间设置为 （ 0—3950/47）之间的随即数“不是太明白，lz能否解释详细一点。。

[ 本帖最后由 zhuyuancan 于 2008-10-20 10:58 编辑 ]

sybilnana

根据日常的操作统计，我们已经得到了服务器基于吞吐量的压力是 47次交互/秒

用LR并发用户数为3950个，每次与服务器交互的时候，就有3950次交互，要模拟47次交互/秒的压力。我们只需要把这3950次请求的压力分散开，怎么分散开呢？可以通过思考时间，我们把一次请求之前的思考时间设置成 3950/47 = 80秒 这个80秒时间段内，随即的某时刻，3950次请求在这80秒中是随即分布的，平均情况下，可以达到47次/秒的压力。

我用LR自带的设定随即时间的功能，跑起来总是出错。有没有人遇到这样的问题？希望帮忙解决一下

wangweiwei2306

楼主分析的有道理，但如果你的脚本中并不是只与服务器有一次交互，即跑一次你的脚本，已经向服务器提交了N次请求，那我们的并发数，是不是需要再除以这个N呢？

judythw

谢谢分享：）

anruy

这样做对服务器的压力远远大于47次/s，试想一下， 假如3950个用户，即使其中有200个人同时到达了等待思考时间的位置，这200个用户都同时等待了47s，那么，在同一s内你对服务器的压力就是200次/s,至于你说的思考时间等待的80s内，又有其他3750个用户或许在进行操作。你只是在时间上平均出每次是这么多压力，但是同一时刻内，系统承受的压力不是47次/s

anruy

这样做对服务器的压力远远大于47次/s，试想一下， 假如3950个用户，即使其中有200个人同时到达了等待思考时间的位置，这200个用户都同时等待了80s，那么，在同一s内你对服务器的压力就是200次/s,至于你说的思考时间等待的80s内，又有其他3750个用户或许在进行操作。你只是在时间上平均出每次是这么多压力，但是同一时刻内，系统承受的压力不是47次/s