tomcat 的并发能力分析

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: tomcat 的并发能力分析

tomcat

参考:Tomcat的3个参数acceptCount、maxConnections、maxThreads

Tomcat 的核心组件

Tomcat 由 2 大核心组件组成:Connector、Container

6087677-b3fe5214269246bd.png


Tomcat 处理请求的过程

请求在 tomcat 服务器的处理过程(BIO 模式)

  1. 客户端与服务端完成三次握手建立了连接,连接信息会存放在 ServerSocket 连接请求的队列中(队列长度为 acceptCount)
  2. 如果提交到线程池的任务数没有超过 maxConnections,那么就 ServerSocket.accept() 返回 socket 对象,封装为任务提交到线程池;

    如果提交的任务数超过了 maxConnections,则阻塞

  3. 任务提交到线程池后,分三种情况:

    • 线程数 <= minSpareThreads:不管有没有空闲线程,都新建线程来处理任务
    • minSpareThreads < 线程数 < maxThreads:新任务会优先使用空闲线程,如果没有空闲线程就新建线程
    • 线程数 == maxThreads:新任务就会在 Connector 创建的 ServerSocket 队列中堆积起来,直到到达最大的配置值(acceptCount 属性值)
  4. 若队列已满,任何再来的请求将会收到 connection refused 错误,直到有可用的资源来处理它们

    当任务被处理完后,则销毁任务以及任务中的 socket 对象,该连接被释放


6087677-e41c8ef4a470b6b5.jpg


Connector 的 protocol(协议)

Connector 在处理 HTTP 请求时,会使用不同的 protocol。不同的 Tomcat 版本支持的 protocol 不同,其中最典型的 protocol 包括BIO、NIO 和 APR(Tomcat7 中支持这 3 种,Tomcat8 增加了对 NIO2 的支持,而到了 Tomcat8.5 和 Tomcat9.0,则去掉了对 BIO 的支持)。

  • BIO(Blocking IO):阻塞的 IO
  • NIO(Non-blocking IO):非阻塞的 IO
  • APR(Apache Portable Runtime):是 Apache 可移植运行库,利用本地库可以实现高可扩展性、高性能;

    Apr 是在 Tomcat 上运行高并发应用的首选模式,但需要安装 apr、apr-utils、tomcat-native 等包。


BIO

在 BIO 实现的 Connector 中,处理请求的主要实体是 JIoEndpoint 对象。

JIoEndpoint 维护了 Acceptor 和 Worker:

  • Acceptor 接收 socket,然后从 Worker 线程池中找出空闲的线程处理 socket,如果 worker 线程池没有空闲线程,则 Acceptor 将阻塞。
  • Worker 是 Tomcat 自带的线程池,如果通过配置了其他线程池,原理与 Worker 类似。

6087677-7a096bcfd0a16d0f.jpg


NIO

在 NIO 实现的 Connector 中,处理请求的主要实体是 NIoEndpoint 对象。

NIoEndpoint 中除了包含 Acceptor 和 Worker 外,还使用了 Poller,处理流程如下图所示:

6087677-357dd01bff9bd51c.jpg

  • Acceptor 接收 socket 后,不是直接使用 Worker 中的线程处理请求,而是先将请求发送给了 Poller,而 Poller 是实现 NIO 的关键。Acceptor 向 Poller 发送请求通过队列实现,使用了典型的生产者-消费者模式。
  • 在 Poller 中,维护了一个 Selector 对象;当 Poller 从队列中取出 socket 后,注册到该 Selector 中;然后通过遍历 Selector,找出其中可读的 socket,并使用 Worker 中的线程处理相应请求。
  • 与 BIO 类似,Worker 也可以被自定义的线程池代替。

在 NIoEndpoint 处理请求的过程中,无论是 Acceptor 接收 socket,还是线程处理请求,使用的仍然是阻塞方式;但在 ”读取socket并交给Worker中的线程” 的这个过程中,使用非阻塞的 NIO 实现,这是 NIO 模式与 BIO 模式的最主要区别(其他区别对性能影响较小,暂时略去不提)。而这个区别,在并发量较大的情形下可以带来 Tomcat 效率的显著提升。


影响并发的 tomcat 参数

  • maxConnections :Tomcat 在任意时刻接收和处理的最大连接数(可以提交给线程池的最大任务数)

    当 Tomcat 接收的连接数达到 maxConnections 时,Acceptor 线程不会读取 accept 队列中的连接(socket);这时 accept 队列中的线程会一直阻塞着,直到 Tomcat 接收的连接数小于 maxConnections。

    如果设置为 -1,则连接数不受限制。

    默认值与连接器使用的协议有关:

    • NIO 的默认值是 10000
    • APR/native 的默认值是 8192

      在windows下,APR/native 的 maxConnections 值会自动调整为设置值以下最大的 1024 的整数倍

      如设置为 2000,则最大值实际是 1024

    • BIO 的默认值为 maxThreads(如果配置了 Executor,则默认值是 Executor 的 maxThreads)
  • acceptCount :允许的最大并发连接数(瞬时连接、瞬时并发数),为 ServerSocket 连接请求的队列长度,默认值为 100

    请求连接在任务队列中时,客户端显示为浏览器显示“转圈”

    当 accept 队列中连接的个数达到 acceptCount 时,队列满,进来的请求一律被拒绝。

    实际场景中,常见的表象是 nginx 响应 502,Tomcat 中没有任何 access 日志,此时应该调大该值。

  • minProcessors:服务器启动时,线程池创建的最少线程数
  • maxProcessorsmaxThreads ):线程池最大连接线程数。默认值为 200

    线程数小于此数时,每次来任务若有空闲线程,使用空闲线程处理,如果没有空闲线程则新建线程处理

    如果该 Connector 绑定了 Executor,这个值会被忽略,因为该 Connector 将使用绑定的 Executor,而不是内置的线程池来执行任务。

    注:

    • maxThreads 规定的是最大的线程数目,并不是实际 running 的 CPU 数量;

      实际上,maxThreads 的大小比 CPU 核心数量要大得多。

      因为处理请求的线程真正用于计算的时间可能很少,大多数时间可能在阻塞,如等待数据库返回数据、等待硬盘读写数据等。

    • 因此,在某一时刻,只有少数的线程真正的在使用物理 CPU,大多数线程都在等待;

      故线程数远大于物理核心数才是合理的。

      换句话说,Tomcat 通过使用比 CPU 核心数量多得多的线程数,可以使 CPU 忙碌起来,大大提高 CPU 的利用率

  • minSpareThreads :线程池最小空闲线程数(多余的空闲线程都将杀死)。默认值为 25

    线程数小于此数时,每次来任务都新建线程处理

  • maxSpareThreads :线程池最大空闲线程数

    一旦创建的线程超过这个值,Tomcat 就会关闭不再需要的 socket 线程

  • maxIdLeTime:一个线程空闲多久算是一个空闲线程,单位:毫秒
  • connectionTimeout :网络连接超时。单位:毫秒。默认值为 60000ms(60秒)

    设置为 0 表示永不超时,但这样设置有隐患的。通常设置为 30000 毫秒或使用默认值

  • disableUploadTimeout :禁用上传超时,主要用于大数据上传时,允许 Servlet 容器正在执行使用一个较长的连接超时值,以使 Servlet 有较长的时间来完成它的执行,默认值为 false
  • enableLookups :是否反查域名,取值为:true 或 false

    若为 true,则可以通过调用 request.getRemoteHost() 进行 DNS 查询来得到远程客户端的实际主机名

    若为 false,则不进行DNS查询,而是返回其 ip 地址

    为了提高处理能力,应设置为 false

补充说明:

  • maxThreads 和 acceptCount 属性对 tomcat 能同时处理的请求数和请求响应时间有直接的影响。

    无论 acceptCount 值为多少,maxThreads 直接决定了实际可同时处理的请求数。

    而不管 maxThreads 如何,acceptCount 则决定了有多少请求可等待处理。

  • 然而,不管是可立即处理请求还是需要放入等待区,都需要 tomcat 先接受该请求(即接受客户端的连接请求,建立socketchannel),那么 tomcat 同时可建立的连接数(maxConnections 属性值)也会影响可同时处理的请求数。


如何设置 acceptCount 、maxConnections、maxThreads 的值:

  • CPU 越不密集(或 IO 越密集),maxThreads 应该越大
  • maxConnections 的设置与 Tomcat 的运行模式有关

    如果 tomcat 使用的是 BIO,那么 maxConnections 的值应该与 maxThreads 一致(默认值为 maxThreads)

    如果 tomcat使用的是 NIO,maxConnections 值应该远大于 maxThreads(默认值为 10000)

  • Tomcat 能够接收的连接数 = maxThreads + acceptCount

    acceptCount 的设置,与应用在连接过高情况下希望做出什么反应有关系

    • 如果设置过大,后面进入的请求等待时间会很长
    • 如果设置过小,后面进入的请求立马返回 connection refused


在线用户数、连接数、瞬时并发数、线程数的区别

  • 在线用户数 = 连接数 + 静态用户数(已登录,但连接已断开,只是在浏览静态数据)(有session对象,没有socket对象)
  • 连接数 = 已接受连接数 + 瞬时并发数(acceptCount:在连接队列里等待的socket对象数)
  • 已接受连接数 = 线程数(RUNNABLE状态)(正在处理)+ 任务队列中的任务数(已接受,待处理)


影响并发的其他限制因素

  • Tomcat 的运行模式

    • BIO(阻塞式的 Socket 通信)模式

      Tomcat8 以下版本,默认的 HTTP 实现是采用 BIO 模式,每个请求都需要创建一个线程处理

      这种模式下的并发量受到线程数的限制,不大适合高并发,但技术成熟。

      每个进程中的线程数受制于操作系统的内核参数设置:

      • Windows 主机每个进程中的线程数不允许超过 2000
      • Linux 主机每个进程中的线程数不允许超过 1000
    • NIO模式(非阻塞式的 Socket 通信)

      Tomcat8 以上版本,默认使用的就是 NIO 模式,在性能上高于阻塞式的,每个请求也不需要创建一个线程进行处理,并发能力比前者高。

    • APR 模式(全称 Apache Portable Runtime)

      是 Tomcat 生产环境运行的首选方式。但必须要安装 APR 和 Native,直接启动就支持 APR。

      APR 是从操作系统级别解决异步 IO 问题。APR 的本质就是使用 JNI 技术调用操作系统底层的 IO 接口,所以需要提前安装所需要的依赖。

      如果操作系统未安装 APR 或者 APR 路径未指到 Tomcat 默认可识别的路径,则 APR 模式无法启动,自动切换启动 NIO 模式。

      注:APR 模式可以提升 Tomcat 对静态文件的处理性能,当然也可以采用动静分离。

  • JVM 调优(tomcat 可以使用的内存)

    Tomcat 是运行在 JVM 上的,所以对 JVM 的调优也是非常有必要的

    在 Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用

    tomcat 默认可以使用的内存为128MB,在并发量较大的应用项目中,这点内存是不够的,需要修改 JVM 参数调优

    • Unix下,在文件{tomcat_home}/bin/catalina.sh的前面,增加如下设置:

      JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'

      需要把这个两个参数值调大。例如:JAVA_OPTS='-Xms256m -Xmx512m'

      表示初始化内存为 256MB,可以使用的最大内存为 512MB

  • 一台主机允许的连接数、线程数、内存大小、硬件性能和 CPU 数量,都会限制实际并发数
  • 并发能力还与应用的逻辑密切相关,如果逻辑很复杂需要大量的计算,那并发能力势必会下降。

    如果每个请求都含有很多的数据库操作(或其他中间件的连接),那么对于数据库的性能要求也是非常高的。

    对于单台数据库服务器来说,允许客户端的连接数量是有限制的(数据库读写的并发能力)

    建议当某个应用拥有 250 个以上并发的时候,应考虑应用服务器的集群


拓展

tomcat 服务器 server.xml 文件

<Server port="8005" shutdown="SHUTDOWN">  
<!-- 属性说明  
    port: 指定一个端口,这个端口负责监听关闭Tomcat的请求  
    shutdown: 向以上端口发送的关闭服务器的命令字符串  
-->  
    <Listener className="org.apache.catalina.core.AprLifecycleListener" />  
    <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />  
    <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />  
    <Listener className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/>  

    <GlobalNamingResources>  
        <Environment name="simpleValue" type="java.lang.Integer" value="30"/>  
        <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" 
                  description="User database that can be updated and saved"
                  factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 
                  pathname="conf/tomcat-users.xml" />    
    </GlobalNamingResources>  
    
    <!--  每个Service元素只能有一个Engine元素。元素处理在同一个<Service>中所有<Connector>元素接收到的客户请求 -->  
    <Service name="Catalina">  
    <!-- 属性说明 name: Service的名称 -->  

        <!-- Connector元素: 由Connector接口定义。<Connector>元素代表与客户程序实际交互的给件, 它负责接收客户请求,以及向客户返回响应结果 -->  
        <Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150" acceptCount="100" 
                   minSpareThreads="25" maxSpareThreads="75" 
                   connectionTimeout="20000" disableUploadTimeout="true" 
                   enableLookups="false" redirectPort="8443" /> 
        <Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />  
        <!--属性说明  
            port: 服务器连接器的端口号,该连接器将在指定端口侦听来自客户端的请求  
            maxThreads: 设定在监听端口的线程的最大数目,这个值也决定了服务器可以同时响应客户请求的最大数目,默认值为200
            acceptCount: 当所有可以使用的处理请求的线程都被用光时,可以放到处理队列中的请求数
                         超过这个数的请求将不予处理,而返回Connection refused错误  
            minProcessors: 服务器启动时创建的处理请求的线程数,每个请求由一个线程负责  
            maxProcessors: 最多可以创建的处理请求的线程数  
            minSpareThreads: 最小备用线程   
            maxSpareThreads: 最大备用线程
            connectionTimeout: 等待超时的时间数(以毫秒为单位)
            disableUploadTimeout: 禁用上传超时,主要用于大数据上传时
            enableLookups: 如果为true,则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名;
                           若为false则不进行DNS查询,而是返回其ip地址
            redirectPort: 服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号
            debug: 日志等级
            protocol: 必须设定为AJP/1.3协议
            address: 如果服务器有两个以上IP地址,该属性可以设定端口监听的IP地址,默认情况下,端口会监听服务器上所有IP地址
        -->

        <Engine name="Catalina" defaultHost="localhost">  
        <!-- 属性说明  
            name: 对应$CATALINA_HOME/config/Catalina中的Catalina   
            defaultHost: 缺省的处理请求的虚拟主机名
                    对应Host元素中的name属性,也就是$CATALINA_HOME/config/Catalina/localhost中的localhost  
                       它至少与其中的一个Host元素的name属性值是一样的  
            debug: 日志等级  
        -->  

            <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> 
            
            <!-- 由Host接口定义。一个Engine元素可以包含多个<Host>元素,每个<Host>的元素定义了一个虚拟主机。它包含了一个或多个Web应用 -->  
            <Host name="localhost" appBase="webapps" autoDeploy="true" unpackWARs="true"  
                  xmlValidation="false" xmlNamespaceAware="false">  
            <!-- 属性说明  
                name: 虚拟主机名。即 $CATALINA_HOME/config/Catalina/localhost中的localhost
                appBase: 默认的应用路径,此路径相对于$CATALINA_HOME/ (web应用的基本目录) 。
                         在autoDeploy为true的情况下,可自动部署应用此路径
                autoDeploy: 默认为true,表示如果有新的WEB应用放入appBase并且Tomcat在运行的情况下,自动载入应用
                debug: 是日志的调试等级
                unpackWARs: 如果为true,在Web应用为*.war时,tomcat会自动将WAR文件解压;
                            否则不解压,直接从WAR文件中运行应用程序
                -->  

                <Context path="/demm" docBase="E:\\projects\\demm\\WebRoot" debug="0" reloadable="true" >   
                </Context>  
                <!-- 属性说明  
                    path: 访问应用的上下文路由URI
                          如果http://localhost/是应用的根目录,访问此应用接口的url前缀为http://localhost/demm
                    docBase: WEB应用的目录。即 web应用的文件存放路径或者是WAR文件存放路径
                              注意:此目录必须符合Java WEB应用的规范
                    debug: 日志等级   
                    reloadable: 是否在程序有改动时自动重新载入。如果为true,则Tomcat将支持热部署,但会影响性能。
                        即可以自动检测web应用的/WEB-INF/lib和/WEB-INF/classes目录的变化,自动装载新的JSP和Servlet。
                        可以在不重起Tomcat的情况下改变web应用。
                -->  
            </Host>  
        </Engine>  
    </Service>  
</Server>  

注:

  • tomcat 启动后会默认占用 8080,8009和 8005 三个端口

    • 8080 端口负责建立 HTTP 连接。在通过浏览器访问 Tomcat服务器的 Web 应用时,使用的就是这个连接器
    • 8009 端口负责和其他 HTTP服务器建立连接。在把 Tomcat 与其他 HTTP 服务器集成时就需要用到这个连接器
    • 8005 端口用来向 Tomcat 发布 shutdown 命令的


对网络端口的理解

  • 实际上,电脑在网卡上的硬件网络端口只有一个。
  • 常说的 1-65535 号端口,并不是真的有这么多个硬件端口,硬件端口实际上只有一个,访问所有端口的数据包都发往这个硬件端口。
  • 硬件端口接收到数据包之后进行解析,然后通知监听对应端口的socket对象来取数据。


并发量计算

参考: 并发量计算

几个概念:业务并发用户数、最大并发访问数、系统用户数、同时在线用户数

  • 假设一个 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 个区间,这样可以解决业务操作存在集中性问题,更趋于精准,偏差更小。


系统吞度量要素

系统吞吐量的几个重要参数:QPS(TPS)、并发数、响应时间

  • QPS(TPS)= 并发数 / 平均响应时间

    • QPS(TPS):每秒钟request / 事务数
    • 并发数: 系统同时处理的request / 事务数
    • 响应时间: 一般取平均响应时间

    (很多人经常会把并发数和 TPS 理解混淆)

  • 一个系统吞吐量通常由 QPS(TPS)、并发数两个因素决定。

    每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了

    如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

  • 系统响应时间,由 CPU 运算、IO、外部系统响应等等组成。


tomcat 高并发配置与优化

参考:tomcat高并发配置与优化

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
5月前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
91 0
|
2月前
|
Arthas Java 应用服务中间件
一次Tomcat返回404的分析
一个Web应用部署在阿里云EDAS上,使用Tomcat 7.0.59.3,在测试环境遭遇所有接口返回404的问题,而生产环境正常。测试与生产环境主要差异在于Apollo配置不同。通过Arthas工具监控,确认Spring已正确加载Controller,并且请求未进入Spring或Filter处理流程。进一步分析发现,Tomcat内部处理流程中设置了404状态码,最终定位到`org.apache.coyote.http11.AbstractHttp11Processor.process`方法存在问题。通过对代码逻辑的分析,确定原因是请求URL路径不正确。修正URL路径后问题得到解决。
46 1
一次Tomcat返回404的分析
|
5月前
|
存储 负载均衡 NoSQL
【分布式技术架构】「Tomcat技术专题」 探索Tomcat集群架构原理和开发分析指南
【分布式技术架构】「Tomcat技术专题」 探索Tomcat集群架构原理和开发分析指南
116 1
|
Arthas 负载均衡 网络协议
Tomcat连接之KeepAlive逻辑分析
Tomcat连接之KeepAlive逻辑分析
332 1
|
监控 算法 Java
java tomcat服务无缘无故挂掉分析和解决方案
最近有同事反应有时候xxx系统有时候会时不时出现服务异常提示,一上机器,发现xxx服务进程不在,重启服务后又恢复了,所以这边就需要去跟进问题。
3099 0
|
Java 应用服务中间件 容器
Tomcat原理系列之三:对请求的过程详细分析
Tomcat原理系列之三:对请求的过程详细分析
Tomcat原理系列之三:对请求的过程详细分析
|
设计模式 安全 Java
【Tomcat技术专题】循序渐进,分析Servlet容器鼻祖的Server和Service组件原理
【Tomcat技术专题】循序渐进,分析Servlet容器鼻祖的Server和Service组件原理
162 0
【Tomcat技术专题】循序渐进,分析Servlet容器鼻祖的Server和Service组件原理
|
Java 应用服务中间件 Maven
springboot项目打成war包放入tomcat中运行,原理分析
1.需要将pom.xml文件的packaging设置为war。 2.改成war包之后,就可以直接使用maven的命令将项目打成一个war包了。 3.将这个war包直接放入到tomcat中运行。 4.启
314 0
|
监控 Java 应用服务中间件
【SpringBoot技术专题】「Tomcat技术专区」用正确的姿势如何用外置tomcat配置及运行(Tomcat优化分析)
【SpringBoot技术专题】「Tomcat技术专区」用正确的姿势如何用外置tomcat配置及运行(Tomcat优化分析)
341 0
|
前端开发 Java 应用服务中间件
Tomcat的启动流程分析
Tomcat的启动流程分析
Tomcat的启动流程分析