服务器并发相关小知识

系统的并发用户数
系统平均的吞吐量
平均每个用户发出的请求数量

首先我基于对你的理解是的是“首页并发访问数”（如果理解不对，是首页并发用户数，也可以根据下面理解转换）
你只提到了首页，访问首页只是业务场景之一，需要你考量所有业务场景。不同网站的业务场景不同。所以你需要根据以下理解，得出自己网站的场景和计算结果。
一些给出涉及概念：
1.业务并发用户数；2.最大并发访问数；3.系统用户数；4.同时在线用户数；
假设一个OA系统有1000用户，这是系统用户数；最高峰同时有500人在线，是“同时在线人数”，也称作“最大业务并发用户数”；500个同时使用系统用户中20%查看系统公告，不构成压力；20%填写表格（只在提交时才会请求，填写对服务器不构成压力）；40%在发呆（什么都没做）；20%用户不停从一个页面跳转另一个页面（只有这20%对服务器产生了压力）。
说明服务器实际压力，能承受的最大并发访问数，既取决于业务并发用户数，还取决于用户的业务场景，这些可以通过对服务器日志的分析得到。
一般只需要分析出典型业务（用户常用，最关注的业务操作）
给出一个估算业务并发用户数的公式（测试人员一般只关心业务并发用户数）
C=nL/T
C^=C+3×(C的平方根)
C是平均的业务并发用户数、n是login session的数量、L是login session的平均长度、T是指考察的时间段长度、C^是指业务并发用户数的峰值。
该公式的得出是假设用户的login session产生符合泊松分布而估算得到。
假设OA系统有1000用户，每天400个用户发访问，每个登录到退出平均时间2小时，在1天时间内用户只在8小时内使用该系统。
C=400×2/8=100
C^=100+3×(100的平方根)=100+3×10=130
另外，如果知道平均每个用户发出的请求数u，则系统吞吐量可以估算为u×C
请注意：精确估算，还要考虑用户业务操作存在一定的时间集中性（比如上班后1小时内是OA系统高峰期），采用公式计算仍然会存在偏差。针对例子OA系统可以把1小时设定为考察时间的粒度，将一天8小时划分为8个区间，这样可以解决业务操作存在集中性问题，更趋于精准，偏差更小。

并发数 为每个连接提供的带宽；假设理想的速度是能够为每个连接提供40KB/S的带宽，而此刻同时有1000人向服务器发出请求，那么1000*40/1024=39M的带宽就可保证计设中的速度。
您可以参考“百度”，
百度的并发量大约是2万左右，百度的每个页面处理时间大约是0.01s。
也就是说百度每秒大约是100万访问量，每小时是3亿访问量左右，每天是50亿访问量到100亿访问量之间。或者您可以参考新浪。
他们已经有很成熟的默式可以支持上万的并发。至于20万的并发，您可以慢慢研究。
“20万同时在线人数”不等于“20万并发”
像CSDN这样几乎所有人都只挂着个“在线”的状态十分钟半小时甚至更久才刷新一次的，20万是很虚的数字…可能并发不过几百…
而20万并发是个可怕的数字，地球上没有哪台单独的服务器可以承受…
另外…任何一款网游有“20万同时在线人数”都可以上新闻了，那得一大堆服务器伺候着…而QQ号称同时在线人数过亿，但大部分人都挂着不说话基本没有流量，即使这样也得一大堆服务器伺候着…

1、通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；
2、Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
3、数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况；