2017年2月 总版技术专家分月排行榜第三
2017年5月 .NET技术大版内专家分月排行榜第一2017年4月 .NET技术大版内专家分月排行榜第一2017年3月 .NET技术大版内专家分月排行榜第一2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
2017年2月 总版技术专家分月排行榜第三
2017年5月 .NET技术大版内专家分月排行榜第一2017年4月 .NET技术大版内专家分月排行榜第一2017年3月 .NET技术大版内专家分月排行榜第一2017年2月 .NET技术大版内专家分月排行榜第一2016年10月 .NET技术大版内专家分月排行榜第一2016年8月 .NET技术大版内专家分月排行榜第一2016年7月 .NET技术大版内专家分月排行榜第一
本帖子已过去太久远了，不再提供回复功能。&&&&&&&&&&&
&&&&&&&&& &答：很多用户在使用e商进销存管理软件及e商系列软件产品的同时，会不清楚并发用户或在线用户的具体含义，这里向用户们具体作出解释。
&&&&&&&&&&&&&&&&& &并发用户和在线用户指的是：同时使用e商系统的在线人数，当用户申请e商正式账号后，我们会为用户分配一个最好权限的系统管理员账号，该账号可以管理整个系统的所有内容，同时可以分配其他员工的登陆账号及其具体操作权限（员工账号数量没有限制）。例如：您申请账号是所申请的并发用户数为5个，那么您整个系统内的有所账号最多只能5个同时在线，若第6用户需要登录，请求前面5个用户中任何一个下线，第6个用户即可登陆。
&&&&&&&&&&&&&&&&&& 并发用户数的计算方法对于连锁零售行业特别有利，以非常低廉的成本实现了对于异地经营的店铺实现了网络化的管理。新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
& &&&在VPN设备选型上，我一般是按照用户数来对VPN设备进行选型，一般按照经验值& &vpn设备的并发隧道数= 用户数*(20%) ，这20%是用户并发数，估算出vpn的并发隧道数之后，再对照相应产品，进行产品选型。
& &请教各位：根据各位的项目经验，这样的办法是否合适，如不合适，根据用户数，如何估算出并发隧道数？
还有一个疑问，隧道与隧道中的并发会话数有什么关系吗?
请各位赐教！谢谢！！
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
请各位给个思路也好
白手起家, 积分 149, 距离下一级还需 51 积分
论坛徽章:0
其实，并发会话数和vpn隧道数是不同的概念。并发会话数是防火墙的范畴
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
原帖由 猫空 于
09:01 发表
其实，并发会话数和vpn隧道数是不同的概念。并发会话数是防火墙的范畴
不是的，“并发会话数是防火墙的范畴”，这样认识并发会话数太狭隘，并发数指的是同时的socket连接数，而VPN并发隧道数指的是，可以同时建立的ipsec sa数 。一个隧道建立后，隧道可以支持多个并发会话。当然如果不通过隧道，直接建立多个SOCKET联接，就是大家常说的防火墙最大可支持的并发数。
感到痛心的是，国内安全厂商的牛皮工夫，一个个吹嘘的防火墙支持百万级的并发数，试试：基于工控机架构的vpn和防火墙能支持万级的并发数，vpn的并发隧道数能支持上千，就算他牛！
我们的环境太浮躁了，缺乏踏踏实实的工作精神！
[ 本帖最后由 datome 于
17:23 编辑 ]
白手起家, 积分 149, 距离下一级还需 51 积分
论坛徽章:0
那你的意思是？
国内的产品都是在骗人的？？那通过压力测试的产品你是怎么理解的〉？？
小富即安, 积分 4664, 距离下一级还需 336 积分
论坛徽章:1
嘿嘿，那个几十万上百万的并发真的不是吹，因为工控机内存大，所以。。。。。。是没有问题di
不过你也可以想象一下，如此高的并发下，恐怕转发都已经不大吃得消了，更何况加解密。
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
原帖由 猫空 于
10:40 发表
那你的意思是？
国内的产品都是在骗人的？？那通过压力测试的产品你是怎么理解的〉？？
看一下这个
Specifications
Advanced Feature/Capacity
ISG 1000 Advanced
ISG 2000 Advanced
Number of Interfaces & & & & 4 fixed 10/100/1000 plus up to 4 Mini GBIC (SX or LX), or up to 8 10/100/1000, or up to 20 10/100 & & & & Up to 8 Mini-GBIC (SX or LX), or up to 28 10/100
Maximum Throughput & & & & 1G FW
1G 3DES VPN & & & & 2G FW
1G 3DES VPN
Maximum Number of Sessions & & & & 250,000 & & & & 512,000
Maximum Number of VPN Tunnels & & & & 2,000 & & & & 10,000
Maximum Number of Policies & & & & 10,000 & & & & 30,000
Maximum Number of Virtual Systems & & & & 10 & & & & 50
Maximum Number of Virtual LANs & & & & 250 & & & & 500
Maximum Number of Security Zones & & & & 20 default, up to 20 additional & & & & 26 default, up to 100 additional
Maximum Number of Virtual Routers & & & & 3 default, up to 10 additional & & & & 3 default, up to 50 additional
High-Availability Modes Supported & & & & Active/Passive
Active/Active
Active/Active Full Mesh & & & & Active/Passive
Active/Active
Active/Active Full Mesh
Routing Protocols Supported & & & & OSPF, BGP, RIPv2 & & & & OSPF, BGP, RIPv1/v2
Deep Inspection & & & & Yes & & & & Yes
Integrated / Redirect Web Filtering & & & & No / Yes & & & & No / Yes
Integrated IDP & & & & Yes - optional upgrade & & & & Yes - optional upgrade
A Baseline software license is available for both the ISG 1000 and the ISG 2000 as an entry-level solution for customer environments where features such as Deep Inspection, OSPF and BGP dynamic routing, advanced High Availability, and full capacity are not critical requirements.
Baseline Feature/Capacity
ISG 1000 Baseline
ISG 2000 Baseline
Sessions & & & & 125,000 & & & & 256,000
Concurrent VPN Tunnels & & & & 1,000 & & & & 1000
VLANs & & & & 50 & & & & 100
Routing Protocols Supported & & & & RIPv2 & & & & RIPv1/v2
High Availability & & & & Active/Passive & & & & Active/Passive
Deep Inspection & & & & No & & & & No
Integrated / Redirect Web Filtering & & & & No / Yes & & & & No / Yes
Integrated IDP & & & & No & & & & No
论坛不支持表格，还是给个联接吧
这是Juniper的千兆级VPN，可是并发隧道数才2000，最大会话数才25万？
白手起家, 积分 44, 距离下一级还需 156 积分
论坛徽章:0
原帖由 < 于
11:17 发表
嘿嘿，那个几十万上百万的并发真的不是吹，因为工控机内存大，所以。。。。。。是没有问题di
不过你也可以想象一下，如此高的并发下，恐怕转发都已经不大吃得消了，更何况加解密。
&&大内存，高CPU可以部分提高并发，但能达到上百万的并发数，就是4G的内存，双CPU的工控机处理百万级的并发，再处理几千个并发隧道，还是远远不够的。
&&百万级的SOCKET联接，几千个RSA\DH的并发运算，想想都可怕。
小富即安, 积分 4664, 距离下一级还需 336 积分
论坛徽章:1
楼上的没理解我的意思，我是说他们的测试数据是光有SOCKET数量，但没有相应的流量。哈哈，不要说几千个RSA\DH的并发运算，就是上百万的SOCKET也很可怕了，不容易啊
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备号 北京市公安局海淀分局网监中心备案编号：22
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处域名与网站(万网)
数加&大数据分析及展现
数加&大数据应用
管理与监控
阿里云办公
培训与认证
数加&人工智能
数加&大数据基础服务
互联网中间件
开发者工具
性能测试 PTS
&&&&&&&&&如何选择并发用户数？
如何选择并发用户数？
更新时间： 13:26:11
&并发用户：指的是现实系统中同时操作业务的用户，在性能测试工具中一般称为虚拟用户(Virutal User)。并发用户跟注册用户、在线用户有很大差别，并发用户一定会对服务器产生压力，在线用户数只是 ”挂” 在系统上对服务器不产生压力，注册用户一般指的是数据库中存在的用户。&&TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个重要指标，&事务靠虚拟用户产生，假如1个虚拟用户在1秒内完成1笔事务，那么TPS就是1，要想达到1000TPS至少需要1000个用户；如果某笔业务响应时间是1毫秒，那么1个用户在1秒内能完成1000笔事务，TPS就是1000。因此1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，主要看响应时间的快慢。&对于并发用户数的选择，可以选取线上系统在高峰时刻一定周期内使用系统的人数，这些人数可以认为是在线用户数，并发用户数取其10%就可以了。例如在1小时内使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。&对于TPS的评估，可以通过线上系统在高峰时刻10分钟内完成的业务量在单位时间的处理笔数计算出TPS&，即业务笔数&/单位时间（10*60&）。&对于新上线系统因没有历史数据可供参考，故只能通过业务发展趋势来预判各项指标。&性能测试需要一套标准化流程及测试策略，在进行压测时一般会按照梯度施压的方式增加用户数，以此观察系统在不同压力下的各种反应，如果在没有充分评估的前提下一次加压大量用户会导致系统失败率高响应时间长，最终得到的测试结果没有太大意义。&一般情况下，大型系统（业务量大、机器多）做性能测试&5000&个并发用户就够了，中小型系统做性能测试&1000&个并发用户就足够了。
本文导读目录
以上内容是否对您有帮助？
更新不及时
缺少代码/图片示例
太简单/步骤待完善
更新不及时
缺少代码/图片示例
太简单/步骤待完善
感谢您的打分，是否有意见建议想告诉我们？
感谢您的反馈，反馈我们已经收到“并发用户数”、“系统用户数”和“同时在线用户数”的计算公式
与并发用户数相关的概念还包括：“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。
假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？
根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。
在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。
（1） 计算平均的并发用户数： C = nL/T
（2） 并发用户数峰值： C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量；L是login
session的平均长度；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login
session产生符合泊松分布而估算得到的。
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。
则根据公式（1）和公式（2），可以得到：
&&&&&&&&&&&&&&
C = 400*4/8 = 200
&&&&&&&&&&&&&&
C’≈200+3*根号200 = 242
&&&&&&&&&&
F=VU * R / T
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
R = T / TS
TS为用户思考时间
计算思考时间的一般步骤：
A、 首先计算出系统的并发用户数
B、 统计出系统平均的吞吐量
F=VU * R / T R&C = VU * R / T
C、 统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
缺陷检测有效性百分比DDE=TDFT/(TDFC+TDFT)&100%
其中:TDFT=测试过程中发现的全部缺陷(即由测试组发现的),TDFC=客户发现的全部缺陷(在版本交付后一个标准点开始测量,如,半年以后)
缺陷排除有效性百分比DRE=(TDCT/TDFT)&100%
其中:TDCT=测试中改正的全部缺陷,TDFT=测试过程中发现的全部缺陷
测试用例设计效率百分比TDE=(TDFT/NTC)&100%
其中:TDFT=测试过程中发现的全部缺陷,NTC=运行的测试用例数
以下公式较适用于白盒测试
功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 （功能点）
需求覆盖率= 被验证到的需求数量 /总的需求数量 （需求）
覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 （测试用例）
语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
判定覆盖率= 判定结果被评价的次数 / 判定结果总数
条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
路径覆盖率=
至少被执行一次的路径数/程序总路径数
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。