当前位置：
  1. 首页
  2. tomcat
  3. 正文
本文介绍: tomcat 的并发能力分析

tomcat

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

Tomcat 的核心组件

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

在这里插入图片描述

Tomcat 处理请求的过程

请求在 tomcat 服务器的处理过程（BIO 模式）

  1. 客户端与服务端完成三次握手建立了连接，连接信息会存放在 ServerSocket 连接请求的队列中（队列长度为 acceptCount）

  2. 如果提交到线程池的任务数没有超过 maxConnections，那么就 ServerSocket.accept() 返回 socket 对象，封装为任务提交到线程池；

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

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

  4. 若队列已满，任何再来的请求将会收到 connection refused 错误，直到有可用的资源来处理它们

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

在这里插入图片描述

Connector 的 protocol（协议）

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

BIO

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

JIoEndpoint 维护了 Acceptor 和 Worker：

在这里插入图片描述

NIO

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

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

在这里插入图片描述

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

影响并发的 tomcat 参数

补充说明：

  • 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 的设置，与应用在连接过高情况下希望做出什么反应有关系

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

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

影响并发的其他限制因素

拓展

tomcat 服务器 server.xml 文件

<Server port="8005" shutdown="SHUTDOWN"&gt;  
<!-- 属性说明  
    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 三个端口

对网络端口的理解

并发量计算

参考： 并发量计算

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

  • 假设一个 OA 系统有 1000 用户，这就是系统用户数
  • 最高峰同时有 500 人在线，是“同时在线人数”，也称作“最大业务并发用户数”
  • 500 个同时使用系统用户中20%查看系统公告，不构成压力；20%填写表格（只在提交时才会请求，填写对服务器不构成压力）；40%在发呆（什么都没做）；20%用户不停从一个页面跳转另一个页面（只有这20%对服务器产生了压力）
  • 服务器实际压力（能承受的最大并发访问数），既取决于业务并发用户数，还取决于用户的业务场景，**这些可以通过对服务器日志的分析得到，**一般只需要分析典型业务（用户常用，最关注的业务操作）。

估算业务并发用户数的公式（测试人员一般只关心业务并发用户数）

  • C = nL / T

  • C^ = C + 3 × (C的平方根)

    • C 是平均的业务并发用户数

  • n 是 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

注意：

系统吞度量要素

参考：系统吞吐量（TPS）、用户并发量、性能测试概念和公式

系统吞吐量的几个重要参数：QPS（TPS）、并发数、响应时间

  • QPS（TPS）= 并发数 / 平均响应时间

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

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

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

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

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

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

tomcat 高并发配置与优化

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

原文地址:https://blog.csdn.net/footless_bird/article/details/128778798

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_13073.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

上一篇 Windows下搭建Tomcat HTTP服务，发布外网远程访问
下一篇 idea构建web项目-超详细教程

相关文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

插入图片
浏览器会保存昵称、邮箱和网站cookies信息，下次评论时使用。