往往也正是因为这些请求性质的不同，Web服务器并发能力强弱的关键便在于如何针对不同的请求性质来设计最优并发策略，这在后续章节中会有详细介绍。同时也是因为有时候一台服务器要同时处理诸多不同性质的请求，在一定程度上使得Web服务器的性能无法充分发挥，这很容易理解，就像银行对不同业务设立不同的窗口一样，这些窗口的服务员分别熟悉自己的窗口业务，可以为不同的客户分别快速办理业务，但是如果让这些窗口都可以办理所有业务，也就是客户可以去任何窗口办理任何业务，那会怎么样呢？相信没有几个银行业务员会对所有的业务都轻车熟路，这样势必会影响到整体的业务办理速度。
　　压力测试的前提条件
　　如果我们要统计吞吐率，便存在一些潜在的前提，那就是压力的描述和请求性质的描述。压力的描述一般包括两部分，即并发用户数和总请求数，也就是模拟多少个用户同时向服务器发送多少个请求，随后会有关于并发用户数的详细介绍。
　　请求性质则是对请求的URL所代表的资源的描述，比如lKB大小的静态文件，或者包含10次数据库查询的动态内容等。
　　所以，吞吐率的前提包括如下几个条件：
　　并发用户数
　　总请求数
　　请求资源描述
　　并发用户数
　　前面提到了并发用户数，在我们开始进行压力测试之前，一定要弄明白它的含义。简单地说，并发用户数就是指在某一时刻同时向服务器发送请求的用户总数。如此多的用户同时请求服务器，显然会给服务器带来不小的压力，这时你可能有一个实际的问题，假如100个用户同时向服务器分别进行10次请求，与1个用户向服务器连续进行1000次请求，效果一样吗？也就是说，给服务器带来的压力一样吗？
　　虽然看起来服务器都需要连续处理1000个请求，其实关键的区别就在于，是否真的“连续”。首先有一点需要明白，对于压力测试中提到的每一个用户，连续发送请求实际上是指在发送一个请求并接收到响应数据后再发送下一个请求。这样一来，从微观层面来看，1个用户向服务器连续进行1000次请求的过程中，任何时刻服务器的网卡接收缓冲区中只有来自该用户的1个请求，而100个用户同时向服务器分别进行10次请求的过程中，服务器网卡接收缓冲区中最多有100个等待处理的请求，显然，这时候服务器的压力更大。
　　其实，并发用户数这个词你也许经常听到，很多时候它还有一些别名，比如并发数、并发连接数等。经常会有人说某个Web服务器能支持多少并发数，除此之外，没有任何上下文，这让很多人摸不着头脑，人们常常把并发用户数和吞吐率混淆，实际上，它们并不是一回事，通过前面的介绍，我们很清楚，吞吐率是指在一定并发用户数的情况下，服务器处理请求能力的量化体现。
　　那么，说一个服务器最多支持多少并发用户数，这个“最多”到底是什么意思？这里我们暂且抛开技术的因素，从广义的角度来看，举个生活中的例子，比如某商城里有一个柜台，给顾客们办理业务。刚开始顾客稀少，一次只来一个顾客，柜台业务员很轻松就可以搞定，不久，有很多顾客去柜台办理业务，大家排成一个长队依次办理，每个顾客在办理业务的过程中，都需要花时间填写一些资料，这时候其他顾客就得等着，而且柜台业务员闲着无聊又不能干别的事情，所以他觉得很浪费时间，就让大家排成两队，这样在等待的时候就给另一个队办理。可是填写资料的时间有点长，另一队的顾客开始填写资料时，前一个队的顾客还没填完，业务员还是得等。最后队伍增加到了10队，10个人同时办理业务，刚好业务员不用等待任何顾客了，而且每个顾客对办理速度也很满意。
　　随着前来办理业务的顾客越来越多，业务员想做点有挑战性的事情，他将队伍增加到了20队，同时给20个顾客办理业务，这下20条队伍拥挤不堪，原本轻松的保安为了维持秩序累得气喘吁吁，这还不算，关键是业务员的办理速度已经赶不上大家填写资料的速度了，一些人填完资料后没人搭理，便开始抱怨，业务员也因为同时要给很多人办理业务，脑子反应不过来，导致处理原本熟悉的业务时也变得手忙脚乱，效率下降且时常伴随一些低级失误。
　　终于，在大家的一片声讨下，柜台崩溃了。注意，柜台的崩溃不是因为业务员无法继续工作了，虽说他忙得累死累活，但是活儿还得干啊，关键是顾客们等得不耐烦了，大部分顾客都无法忍受长时间的等待以及办理过程中出现的错误，所以投诉到了商城的管理处，商城只好暂时关闭柜台业务，商讨对策。
　　很快，商城又恢复了柜台业务，将柜台的队伍数调整到10队，同时根据顾客流量，临时增设一定数量的柜台，这样一来，顾客们纷纷表示满意。
　　我们可以说，这个柜台支持的最大并发数为10，因为恰好在这个并发数下，柜台业务开展得非常成功，顾客们都对服务时间非常满意，而且此时代表业务办理次数的柜台吞吐率也比较高，商城和顾客实现双赢。当并发数少于10的时候，柜台业务员的时间得不到充分利用，浪费了柜台的宝贵资源，这时候的吞吐率要低一些。而当并发数大于10的时候，事实证明，顾客们不乐意了。这样看来，问题的本质变得非常清晰，似乎就是商家和顾客的博弈，而且是合作型博弈，最大并发数便是博弈的结果，也是最大程度的共赢。
　　可见，通常所讲的最大并发数是有一定利益前提的，那就是服务器和用户双方所期待的最大收益，服务器希望支持高并发数及高吞吐率，而用户不管那么多，只希望等待较少的时间，或者得到更快的下载速度，显然，双方不可能都彻底满足，所以便存在讨价还价的余地，同时双方也都有能够忍受的最低尺度。从经济学的角度看，就这么简单，所以找到双方利益的平衡点，便是我们所希望的最大并发用户数。这种现象在后续章节中介绍下载服务的时候还会提到。
　　当然，经过权衡后，我们所希望的最大并发用户数还存在一定的技术制约，这也是狭义层面的最大并发数的定义。柜台的故事只是一个简单的模型，而在我们访问实际的Web站点时，每个请求的处理过程并不像柜台业务员给顾客办理业务那么简单，尤其是在并发用户数较大的情况下，Web服务器使用什么样的并发策略，是影响最大并发数的关键。
　　另外值得说明的是，即使我们通过压力测试得出服务器支持的最大并发数，但这与实际并发用户数却是两回事，因为有多少用户同时发来请求并不是服务器所能决定的，该来的总是要来，那是客观存在的。一旦实际并发用户数大于服务器所能支持的最大并发数，那必然造成一部分用户需要等待超过预期的时间，影响了站点的服务质量。所以，得出最大并发数的意义，在于了解服务器的承载能力，并且结合用户规模考虑适当的扩展方案。从站点的某些商业角度来看，最大并发用户数的支持程度往往比吞吐率更加容易理解。
　　在考虑实际用户规模的时候，我们还需要了解一点，用户访问Web站点通常使用浏览器，而浏览器在下载一个网页以及网页中的多个组件时，采用多线程的并发下载方式，但是对于同一域名下URL的并发下载数是有最大限制的，具体限制视浏览器的不同而不同，比如，在：HTTP／1.1下，IE 7支持两个并发连接，IE 8支持6个并发连接，Firefox 3支持4个并发连接，我们使用诸如HttpWateh这样的HTTP监视工具可以很清晰地看到这一点。所以，我们前面说到的服务器支持的最大并发数，具体到真实的用户，可能并不是一对一的关系，一个真实的用户可能会给服务器带来两个或更多的并发用户数的压力，一些高明的用户还可以通过一些方法来修改浏览器的并发数限制。而我们在本书中为了简化模型，暂且认为每个用户的并发下载数均为1。
　　另一方面，从Web服务器的角度来看，实际并发用户数也可以理解为Web服务器当前维护的代表不同用户的文件描述符总数，也就是并发连接数，当然，不是同时来了多少用户请求就建立多少连接，Web服务器一般会限制同时服务的最多用户数，比如Apache的MaxClients参数，所以这个实际并发用户数，有时候大于服务器所维护的文件描述符总数，而多出的这些用户请求，则在服务器内核的数据接收缓冲区中等待处理，所以这些请求在用户看来处于阻塞状态。
　　……