说：“如果请求的平均服务时间为X且请求的可承受等待时间为Y，那么服务的并发请求的最大数量将为Y / X”这是合乎逻辑的吗？
我认为我要问的是，如果有任何隐藏因素我没有考虑到这一点！？
答案 0 :(得分：2)
大致上是的，但是您的服务提供商（在您的情况下是网络服务器）能够并行处理多个请求，因此您应该考虑到这一点。我假设您测量了端到端服务时间，并且还没有按并行流的数量对其进行平均。你没有也无法实际衡量的另一件事是你网站的延迟。
您要前进的是Erlang单元（不是使用相同名称的语言），用于描述系统可以承受多少负载。 Erlangs是无单元的（它只是一个数字）并且起源于旧学校电话POTS，在那里它用于描述每个时间段以低阻塞概率处理X个呼叫需要多少线路。超越erlang是engset，它更多地用于高容量系统，例如移动系统。
它还用于向实时计算机系统和数据库提供昂贵的顾问报告，以描述可能发生性能下降的点。维基百科有一篇关于这个http://en.wikipedia.org/wiki/Erlang_(unit)的文章，“固定和移动电信，网络系统和服务”这本书在性能分析方面有很好的篇章。
虽然针对的是电话系统，但只需使用word webserver替换它，它的行为相同。网络服务器是相同的概念，提供的负载以随机间隔到达具有有限并行容量的系统。在您的情况下，您可以使用加载工具计算总负载比并行容量更容易，然后返回计算公式。这样做是为了获得对整个系统模型的信心。
当你有一个随机到达的并行流加载（即网络请求）和一个只能平均或估计的服务时间（即它在现实生活中变化）时，Erlang / engsetformulas非常有用。然后，您可以计算阻塞概率，即新请求在服务当前请求时需要等待的概率，以及等待的时间。它还有助于分析您是否需要并行处理更多请求，或者更快地完成每个请求（#lang中的#lines和保持时间说话）
接下来你可能会考虑排队系统分析，因为一旦请求阻塞（队列），模型就会稍微改变。
答案 1 :(得分：2)
如果您正在谈论网络服务器，那么不，您的公式不起作用，因为网络服务器旨在使用forking or threading处理多个同时请求。
这使公式变得更难以量化 - 根据我的经验，Web服务器可以处理LOTS（即数百或数千）并发请求，这些请求消耗很少或没有时间，但往往会因请求而大大减少并发性消耗更多时间。
这意味着“平均服务时间”并不是非常有用 - 它可以隐藏广泛的变化，而实际上是影响您的异常值。
答案 2 :(得分：1)
未考虑许多因素
尽管如此，粗略估计的一个简单方法是使用apache ab工具（apache benchmark）
示例，一次获得1000次主页，包含100个请求：
ab -c 100 -n 1000 http://www.example.com/