Tomcat系列

一，Tomcat的目录结构

webapp： 代码工程部署放在这个目录下

bin：一些启动文件（*.bat(windows下启动)    *.sh(linux下启动或者关闭)    catalina.sh (配置JVM)）

常用的命令：

　　sh startup.sh  启动tomcat服务

　　sh shutdown.sh   停止tomcat服务

　　kill -9 + pid（进程号）   强制停止服务

　　netstat -ntlp：查看网络

　　jps： 查看Java的进程

　　lsof -f ：展现文件地址启动的服务

　　tail -f :可以实时的查看文件的内容

 

logs:存放一些日志文件，比如：catalina的日志，hostmanage日志，localhost_access_log记录用户的请求日志，manager日志。

lib：  tomcat使用到的jar包  如：dbcp.jar，  jdbc.jar。

conf：配置文件（server.xml    tomcat-user.xml）

 

 二，tomcat的配置

2.1 server.xml配置（占用了三端口：8005，8009,8080）

8005端口：shutdown端口

8080端口：对接用户的请求

8009端口：暂时还不请求

 maxThreads：tomcat启动的最大线程数量默认值是200，每1个线程处理1个并发请求。

acceptCount：同时并发的请求数达到maxThreads时，还可接受排队的请求个数，超过此数直接拒绝，默认值是100

connectTimeout：当并发请求和8080服务器建立连接开始，等待服务器放回响应结果的时间（单位是ms）

enableLookups：是否允许反向解析访客的IP地址，默认值为true。

如图所示：

2.2 工作原理

情况1：

　　当 同时进来并发请求数< 200 时，tomcat启动的线程数没有达到maxThreads数

　　当tomcat服务8080接收1个请求，tomcat会启动一个线程来处理此请求；过程即Jmeter--A --C

情况2：

　　当同时进来并发请求数>200时，tomcat启动的线程数即达到maxThreads数

　　当tomcat服务8080接收1个请求，tomcat会把此请求放入等待队列，等待空闲线程。

情况3：

　　当同时进来并发请求数>200时，acceptCount排队数>100

　　当tomacat服务8080接收1个请求，此时tomcat会直接拒绝此请求，返回connection refused。

 2.3 常见问题

Q1：maxThreads数满或不断上升的原因：

答：1，并发量大

　　2，代码有瓶颈造成maxThreads配置的线程不能释放掉

Q2：acceptCount 数满或不断上升原因：

答：1，并发量大，maxThreads数达到最大值

　　2，代码有瓶颈，造成maxThreads配置的线程不能释放掉

Q3：connectTimeOut超时原因：

答：1，当Jmeter或者浏览器给tomcat的8080端口发送请求，建立连接的时间超过connectTimeOut设置的时间就会连接超时

　　什么时候会超过connectTimeout的时间呢？

　　1，当网络慢，卡顿，丢包严重会引起

　　2，当Jmeter到tomcat再到webapps，后webapps到tomact再返回给Jmeter，这四段的总时间超过connectTImeOUt时间。

 

　　3，当acceptCount中的等待请求超过connectTimeOut设置的时间没有请求，则请求超时

 

Q4，connectRefused原因：

答：并发请求量大于maxThreads + acceptCount总和

三，Tomcat的监控

3.1 监控tomcat（jvm，线程等）

1，在conf目录下配置tomcat-user.xml文件后重启。

 

 2，在前端登录manager webapp

进入到serverStatus

 

3.2，监控tomcat每秒并发

查看localhost_access_log.2020-08-23.txt

 

 通过监控localhost_access_log.2020-08-23.txt日志，来监控tomcat每秒并发

方式1：awk '{print $4}' localhost_access_log.2020-08-23.txt   (统计每一行的第四列)

 

 

 awk '{print $4}' localhost_access_log.2020-08-23.txt  | sort -r   （sort -r 将排序反转） | uniq -c (统计重复行)  | head -10   （只看前10条数据）

 

 

 统计接口数
awk {print $7}   localhost_access_log.2020-08-23.txt    # 统计每一行的第7列的接口地址

awk {print $7}   localhost_access_log.2020-08-23.txt  | sort -n  | uniq -c 

sort -n 做排序   uniq -c  去重统计次数  sort -nr 升序排序再反转

 

awk {print $7}   localhost_access_log.2020-08-23.txt  | sort -n  | uniq -c | sort -nr

sort -nr 升序排序再反转

 

 

 awk {print $7}   localhost_access_log.2020-08-23.txt  | sort -n  | uniq -c | sort -nr | head -10 

sort -nr 升序排序再反转  ，head -10 看前10的

 

awk {print $1}   localhost_access_log.2020-08-23.txt  | sort -n  | uniq -c | sort -nr | head -10    统计ip地址的访问次数

 

 方式2，通过Jmeter并发请求数

 四，Tomcat总结

4.1 压测总结

 A ：Jmeter请求数 > maxThreads

        jmeterq请求数> (maxThreads+acceptCount)

　　若响应时间逐步增大时，说明tomcat长时间不返回响应数据，即tomacat线程不能释放，故此时tomcat就要不断用新线程对接请求，主要原因是：

　　　　linux硬件配置低，tomcat最大线程数配置低，代码瓶颈

　　若响应时间<1s时，tomacat底层出少部分线程对接

B：Jmeter请求数<maxThreads

　　Jmeter 请求数<(maxThreads+acceptCount)

　　若响应时间逐步增大时，说明tomcat长时间不返回响应数据，即tomcat线程不能释放，故此时tomcat就要不断用新线程对接请求，主要原因：

　　　　linux硬件配置低，tomcat最大线程数配置低，代码瓶颈

 

5.2，tomcat线程配置规则

规则:tomcat 部署的相关代码无瓶颈 + 压测关注linux服务器资源使用情况（cpu 75%，mem75%）

 案例总结：响应时间逐步变大，说明服务器处理能力下降，据监控linux负载低，tomcat线程用的少，且tomcat不参与代码计算

，只是起承上启下的作用，故此问题就是代码瓶颈，此时tomcat配置就毫无意义，当前应优先解决代码瓶颈问题。

 

 经验：

1，响应时间越大，并发请求数一定会低，tomacat启动线程数一定越来越多。

2，响应时间越小，并发请求数一定会高，tomcat启动线程数一定是很少的。