服务器 最大连接数：

服务器可以设置

 max_Threads  = 150  最大线程数量(最大并发数量，或者说最大的并发用户量) （可以处理连接的线程数量）

 accept_count 如果服务器中所有线程都在工作，那排队的请求连接的数量 的值。

这样看 服务器 的最大线程数量 为 150 个。

最多 连接  1150 个。

第1151 个连接请求的时候，会等待connection_timeout 秒，如果没有  线程处理  甚至没有 放入 请求队列，则返回超时。

如果 放入了请求队列，也会设置一个 discard 超时时间， 如果在时间段内没有处理，也会 返回给客户端  超时 。

 

根据什么判断设置 maxThread  ?

Tomcat的最大并发数是可以配置的，而且并没有限制你所配置的并发数数量，需要根据你的应用处理request所需要的带宽，CPU,内存，压力等进行配置。

还有一种说法是Tomcat的理论并发数量极限是服务器最大可用的端口数，也就是最多65536个，但是我并不确定这是正确的。

操作系统对于进程中的线程数有一定的限制：

1. Windows 每个进程中的线程数不允许超过 2000
2. Linux 每个进程中的线程数不允许超过 1000
3. 在Java中每开启一个线程需要耗用1MB的JVM内存空间用于作为线程栈之用，此处也应考虑
4. 实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。
5. 
   
6. 用户平均请求等待时间：
7. 服务器平均请求处理时间：
8. 用户平均请求等待时间主要用于衡量服务器在一定并发用户数的情况下，对于单个用户的服务质量
9. 服务器平均请求处理时间与前者相比，则用户衡量服务器的整体服务质量，它其实就是吞吐率的倒数。
10. 
    

吞吐率： 是指每秒的处理的请求数量／传输的数据量

吞吐量：一个时间段内 处理的请求数量/传输的数据量。

最大并发数：瞬间最大的并发请求数量(不会timeout)。

最大并发用户数是指在某一时刻同时向服务器发送请求的用户总数（不会timeout）

通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的性能瓶颈。

压力测试 ：就是最大并发用户数量的测试。

吞吐率测试 ：就是单位时间内处理的请求数量的限制。

一般系统的瓶颈 就在  最大并发用户数 和 吞吐率 两个方面。

如果系统支持的最大并发用户数量 太少，怎么办？

设置max_thread 为一个 更大的值，理论上来讲，线程数越多，可以同时 处理的连接就越多。

如果系统的吞吐率太低，也就是每秒处理的请求数太少 ，怎么办？

原因：

1 线程少，处理的请求就少。

2 线程足够多，处理的连接数量还不到线程数量，说明 服务器内部，处理逻辑有问题。

一般获取连接timeout 是因为线程都已经占满了，并且 服务器 队列占满了，这说明线程处理能力也一般吧，或者 代码内部的处理逻辑有问题。

dubbo :  连接属性 

dubbo.provider.connections  ＝20  这个属性是每个provider  允许的连接数。

如果 一个项目里有10个provider ，

那这个项目的最小总连接数 就是 20 ＊10 = 200

但是如果某个provider 被调用的特别频繁，那20连接肯定不够用了，

就要把多的请求放到队列里。

这个队列有多大，就看请求的数量了。

设置可以连接的队列大小的属性 ；

dubbo.protocol.accepts=10000