并发计算公式

常用并发数计算公式：N=[(n08SP)/(T02)]R
其中：n为系统用户数；

S为每个用户发生的业务笔数（QPS）；

P为每笔业务所需要访问服务器的时间，单位为秒；

T为使用业务的时间，单位为秒；

R为调节因子，缺省值为1；

示意：

S=20（每天1000个用户发生20000笔业务）；

P=30（每笔业务需要访问服务器30秒）；

T=36000（每天工作10小时）；

R=2（缺省为1，复杂的业务系统可用2）；

计算得出的并发数为：（1000082030/(3600002)）2=13333；
一、经典公式
1：一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据
1）平均并发用户数为 C=nL/T
2）并发用户数峰值 C'=C+3根号C
C是平均并发用户数，n是 Login session的数量，L是 Login session的平均长度，T是值考察的时间长度
C'是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志中获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时内会使用该系统。
那么，
平均并发用户数为：C=4004/8=200
并发用户数峰值为：C'=200+3根号200=243
举例2，某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会使用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）：
n=1700000507/5=11900
C=119005/60/8=124
吞吐量计算为：F=VuR/T 单位为个/s
F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间
二、通用公式2：
对绝大多数场景，我们用（用户总量/统计时间）影响因子（一般为3）来进行估算并发量
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为5000080%/（36060）=37，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s3s=12，当然影响因子可以根据实际情况增大！
三、根据PV计算公式：
比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：
1000w80%/(93600)=24692个/s，取经验因子3，则并发量应为：
246923=740
四、根据TPS估计：
公式为C=（Think time+1）TPS
五、根据系统用户数计算：
并发用户数=系统最大在线用户数的8%到12%

Tps即每秒处理事务数,包括了 1)用户请求服务器 2)服务器自己的内部处理 3)服务器返回给用户 这三个过程,每秒能够完成N个这三个过程,Tps也就是3;
2
Qps基本类似于Tps,但是不同的是,对于一个页面的一次访问,形成一个Tps;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“Qps”之中。 例如:访问一个页面会请求服务器3次,一次放

单服务器容器规模指的是在一台服务器上运行多个容器实例的数量。这个数量通常受到服务器硬件资源的限制，如CPU、内存、磁盘空间等。对于一台具有良好硬件配置的服务器来说，可以运行数十甚至上百个容器实例。
但是，容器的规模并不仅仅与硬件资源有关，还与应用程序的特性有关。例如，一个I/O密集型的应用程序会大量使用磁盘I/O，可能会使磁盘资源成为瓶颈，从而影响容器的规模。另一个例子是内存密集型应用程序，可能会需要大量的内存才能支持运行，从而限制容器的数量。
因此，在确定单服务器容器规模时，需要考虑应用程序的特性和硬件资源的限制，并进行实际测试和评估，以确定最适合的容器数量。同时，还需要考虑容器之间的互相影响，以避免容器间的资源竞争和瓶颈问题。

Apache服务器也就是采用>