并发的概念：
指网站在同一时间访问的人数，人数越大，瞬间带宽要求更高。
服务器并发量分为：
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。
服务器压力计算(转载：https://www.cnblogs.com/ylcms/p/7738692.html） 你想建设一个能承受500万PV/每天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？如果计算呢？
PV是什么： PV是page view的简写。PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。
计算模型： 每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。 其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。
简单计算的结果： ((80%500万)/(24小时60分60秒40%))/1 = 115.7个请求/秒 ((80%100万)/(24小时60分60秒40%))/1 = 23.1个请求/秒
初步结论： 现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。
留足余量： 以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。 115.7个请求/秒 *2倍=231.4个请求/秒 115.7个请求/秒 *3倍=347.1个请求/秒 23.1个请求/秒 *2倍=46.2个请求/秒 23.1个请求/秒 *3倍=69.3个请求/秒
最终结论： 如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。 如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。
说明： 这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。
实际经验： 1、根据实际经验，采用两台常规配置的机架式服务器，配置是很常见的配置，例如一个4核CPU+4G内存+服务器SAS硬盘。
2、硬盘的性能很重要，由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘，高级一点的可以配SSD固态硬盘，性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。（本例还是配置最常见的1.5万转的SAS硬盘吧） 3、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化)，是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。 4、以上软硬件情况下，是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰)
注意机房的网络带宽： 有人说以上条件我都满足了，但实际性能还是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。 一天总流量：每个页面20k字节*100万个页面/1024=19531M字节=19G字节， 19531M/9.6小时=2034M/小时=578K字节/s 如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB 注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。 以上是假设每个页面20k字节，基本不包含图片，要是包含图片就更大了，10M带宽也不能满足要求了。你自已计算吧。 （全文完）
附：性能测试基本概念
基本概念： Throughput（吞吐量）：按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡，最大发送数据的速度是12.5M字节/s ， 最大接收数据的速度是12.5M字节/s， 可以 同时 收发 数据。 并发用户数：是同时执行操作的用户(线程数)。 响应时间：从请求发出到收到响应花费的时间 。
QPS - Queries Per Second 每秒处理的查询数（如果是数据库，就相当于读取） TPS - Transactions Per Second 每秒处理的事务数(如果是数据库，就相当于写入、修改) IOPS，每秒磁盘进行的I/O操作次数
例如对某个数据库测试，分开两次测QPS与TPS。 QPS（读取）值总是高于TPS(写、改)，并且有倍率关系，因为： 1、数据库对查询可能有缓存。 2、机械硬盘或SSD硬盘的读就是比写快。
JMeter测试参数说明：
Label：每一个测试单元的名字。
#Samples：表示一个测试单元一共发出了多少个请求。
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间。，不重要。
Median：中位数，也就是 50％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。重要。
90% Line：90％ 用户的响应时间，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要 。
Min：最小响应时间，不重要。
Max：最大响应时间，出现几率只不过是千分之一甚至万分之一，不重要。
Error%：本次测试中出现错误的请求的数量
Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收 到的数据量(只是接收)，相当于LoadRunner中的Throughput/Sec
loadrunner测试参数说明：
响应时间： 取90%值，如果把响应时间从小到大顺序排序，那么90％的请求的响应时间在这个范围之内。重要。
每秒点击数 ：hits per Second,每秒钟向服务器提交请求的数量。
TPS： Transaction per Second ，每秒事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程
Throughput（吞吐量）： Loadrunner记录的Throughput是接收到服务器返回的所有字节数之和，与本地发出的字节数无关。
Throughput/Sec： 每秒的吞吐量。
对于BS架构的一般分析 响应时间、点击率、吞吐量、TPS（每秒事务数）。 对于CS架构的一般分析 TPS（每秒事务数）