微软SQL Server 2008 R2 标准版(25用户)最大并发连接数是多少？及支持多少客户端同时访问

SQL Server 2008支持并发的连接数分两种情况：

1）不启用连接池

当创建到101个连接的时候，就无法再创建新连接了。也就是说，如果连接字符串不做任何处理，我们的程序只能够跟SQLServer建立101个连接。

2）启用连接池

在连接字符串中加入代码：

Pooling=true;Max Pool Size=40000;Min Pool Size=0;

微软在MSDN上对最大连接数的定义是：“默认是0，代表不限制，但最大连接数是32767。

SQL Server支持同时访问的客户端数量：

开发版、速成版有客户连接限制，一般是10个连接。企业版、标准版没有限制，硬件能支持多少就能支持多少。

扩展资料

sql server 2008 R2 连接数过高的解决办法：

由于公司最近两个Web站点做了负载均衡，但是缓存机制仍然是 AspNet 自带的缓存，这样就导致了每台Web 服务器内存中都有一份缓存，直接导致了多次请求DB数据库，造成了DB连接数过高。

由于是两个较大的站点两台服务器做负载均衡（负载平衡），所以，DB 的连接数也飙升，几乎翻了3倍。

公司DB服务器用的是 Sql Server 2008 R2 ，并且DB服务器配置是相当的强悍的，连接数一度冲击到740，真是让人惊叹不已。虽然链接数强悍，但是前台访问的页面 超时的 也是茫茫多，没办法，只能采用了紧急处理：

1、加大程序中的缓存，特别是页面头部加上 OutPutCache 缓存。

2、用上镜像的备份DB服务器，把2个站点的DB链接改到了镜像的DB，这台镜像DB和现在主DB是不在同一个机房的，目标就是容灾和在高流量的情况下快速切换

计算模型： 

每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。

其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是96小时，有80%的请求发生一天的96个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。 简单计算的结果：

((80%500万)/(24小时60分60秒40%))/1 = 1157个请求/秒 

((80%100万)/(24小时60分60秒40%))/1 = 231个请求/秒

现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理1157个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理231个请求，就可以承受100万PV/每天

有人说以上条件我都满足了，但实际性能还是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。

一天总流量：每个页面20k字节100万个页面/1024=19531M字节=19G字节，

19531M/96小时=2034M/小时=578K字节/s   如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB

注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。

以上是假设每个页面20k字节，基本不包含，要是包含就更大了，10M带宽也不能满足要求了。

具体设置：

第一步：启用MPM模块配置文件

我们需要在httpdconf文件中启用该配置文件，如下所示：

# Server-pool management (MPM

specific)Include conf/extra/httpd-mpmconf (去掉该行前面的注释符号"#")

第二步：启用MPM模块后找到配置文件进行编辑。

在Apace安装c:\ chaodiquancom \conf\extra目录中有一个名为httpd-mpmconf的配置文件。该文件主要用于进行MPM模块的相关配置。不过，在默认情况下，Apache的MPM模块配置文件并没有启用。

第三步：此时，我们就需要根据当前Apache服务器所使用的MPM模块，来修改对应节点下的参数配置。首先，我们来看看mpm_winnt模块下的默认配置：

#由于mpm_winnt模块只会创建1个子进程，因此这里对单个子进程的参数设置就相当于对整个Apache的参数设置。

ThreadsPerChild    150 #推荐设置：小型网站=1000 中型网站=1000~2000

大型网站=2000~3500MaxRequestsPerChild   0 #推荐设置：小=10000 中或大=20000~100000

对应的配置参数作用如下：ThreadsPerChild

每个子进程的最大并发线程数。

MaxRequestsPerChild

每个子进程允许处理的请求总数。如果累计处理的请求数超过该值，该子进程将会结束(然后根据需要确定是否创建新的子进程)，该值设为0表示不限制请求总数(子进程永不结束)。

该参数建议设为非零的值，可以带来以下两个好处：

可以防止程序中可能存在的内存泄漏无限进行下去，从而耗尽内存。

给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。

1、在linux下，一个进程而言最多只能打开1024个文件，所以采用此默认配置最多也就可以并发上千个TCP连接。而通过临时修改：ulimit -n 1000000，就可以达到100万个TCP连接。但是这种临时修改只对当前登录用户目前的使用环境有效，系统重启或用户退出后就会失效。

2、端口限制：操作系统上端口号1024以下是系统保留的，从1024-65535是用户使用的。由于每个TCP连接都要占一个端口号，所以我们最多可以有60000多个并发连接。

3、因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。

4、上面给出的结论都是理论上的单机TCP并发连接数，实际上单机并发连接数肯定要受硬件资源（内存）、网络资源（带宽）的限制，至少对现在可以做到数十万级的并发了。

IIS连接数指并发连接数要分几种情况：1用户打开你的页面，就算停留在页面没有对服务器发出任何请求，那么在用户打开一面以后的20分钟内也都要算一个在线，就是说你50人的网站20分钟内可以接受不同用户打开50个页面2上面B的情况用户继续打开同一个网站的其他页面，那么在线人数按照用户最后一次点击（发出请求）以后的20分钟计算，在这个20分钟内不管用户怎么点击（包括新窗口打开）都还是一人在线。3当你的页面内存在框架(Iframe)，那么每多一个框架就要多一倍的在线！因为这相当于用户同一时间向服务器请求了多个页面。4当用户打开页面然后正常关闭浏览器，用户的在线人数也会马上清除。