服务器的并发数与什么有关
① 并发与迭代
例如在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、内存、硬盘都没问题，也会因为租用的网络带宽限制而影响最大的并发数。