利用Ubuntu Tomcat日志进行性能基准测试

基于 Tomcat 日志的 Ubuntu 性能基准测试方案

一 目标与总体思路

• 以 Tomcat 的访问日志为主，量化关键指标：吞吐量（RPS）、响应时间分布（p50/p95/p99）、错误率、并发线程/连接数趋势，并与 GC 日志、系统资源交叉验证，形成可复现的基准。
• 日志来源与用途：
  • localhost_access_log：用于计算 RPS、响应时间、错误率等核心指标。
  • catalina.out / localhost.log*：用于错误与异常定位、线程池饱和迹象。
  • GC 日志：用于停顿与回收压力验证（与业务日志时间对齐）。
  • 系统资源：用 top/htop/vmstat/iostat 观察 CPU、内存、I/O 是否与日志指标一致。

二 环境与日志准备

• 目录与文件
  • Tomcat 日志默认在 $CATALINA_HOME/logs 或 /var/log/tomcatX/；常见文件：catalina.out、localhost_access_log.*.txt、localhost-*.log。
• 访问日志必须输出响应时间
  • 在 conf/server.xml 的 Host 内确保存在 AccessLogValve，并使用能输出处理时间的 pattern（示例见下文）。若缺失，将无法从日志直接计算响应时间与 RPS。
• 日志轮转与保留
  • 使用 logrotate 管理 catalina.out 等日志，避免单文件过大影响分析与采集；可按日切分并设置保留天数。
• GC 日志开启（用于与业务指标对齐）
  • 在 bin/catalina.sh 的 JAVA_OPTS 增加：
    • -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:$CATALINA_HOME/logs/gc.log
    • 建议同时开启 -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，便于长期压测归档。

三 执行测试与日志采集

• 稳定环境与预热
  • 选择固定硬件/云实例规格，保持 JVM 与 Tomcat 参数一致；先以低强度运行 5–10 分钟预热（避免 JIT/缓存造成首轮失真）。
• 运行基准
  • 使用 JMeter、k6、wrk2 等工具产生稳定负载（固定并发/固定 RPS/阶梯加压），持续 10–30 分钟；保持应用在稳定窗口内运行，便于计算分位数与趋势。
• 同步采集
  • 压测期间持续 tail -f 观察 catalina.out 是否有异常堆栈；记录测试起止时间与负载特征（并发、RPS 目标）。
  • 压测结束后，立即拷贝 localhost_access_log、catalina.out、gc.log 到分析目录，避免轮转覆盖。

四 日志解析与指标计算

• 访问日志字段约定
  • 推荐 pattern（包含响应时间，单位毫秒）：
    • %h %l %u %t “%r” %s %b “%{ Referer} i” “%{ User-Agent} i” %D
    • 其中 %D 为“请求处理时间（微秒）”，便于计算 p50/p95/p99 与 RPS。
• 示例指标计算（Linux 命令行）
  • 总请求数
    • wc -l < access_log | awk ‘{ print $1} ’
  • 平均/分位响应时间（ms）
    • awk -F’"’ ‘{ print $NF/1000} ’ access_log | sort -n | awk ‘{ a[NR]=$1} END { print "p50="a[int(NR0.5)],"p95="a[int(NR0.95)],"p99="a[int(NR*0.99)]; sum+=$1; n++; } END { print "avg="sum/n/1000} ’
  • 吞吐量 RPS（按日志时间窗口）
    • 以日志首条时间为基准，计算测试时长 T（秒），RPS = 总请求数 / T。
  • 错误率
    • awk ‘$9 ~ /^[45]/ { err++} END { print “errors=” err; print “error_rate=” err/NR} ’ access_log
  • 峰值并发估算（Little 定律）
    • 在稳定窗口内，取 平均响应时间 RT（秒） 与 RPS，估算并发 C ≈ RPS × RT；与线程池配置对比判断是否饱和。
• 可视化与长期对比
  • 小规模可用 ELK（Filebeat/Logstash/Elasticsearch/Kibana） 或 Graylog 搭建仪表盘，按时间段对比 RPS、p95/p99、错误率 与 GC 次数/停顿 的联动关系。

五 判定与优化建议

• 判定基线
  • 以“稳定窗口”的指标作为基线：RPS 稳定、p95/p99 不随并发线性恶化、错误率可接受（如 < 0.5%）、GC 停顿与回收次数在目标范围内。
• 线程池与连接器调优（server.xml）
  • 结合并发与 RT 调整 maxThreads、minSpareThreads、acceptCount、connectionTimeout；若发现线程饱和且排队明显，可适度提升 maxThreads 或优化慢请求；若 CPU 空闲但 RPS 上不去，检查数据库/外部依赖与网络。
• JVM 与 GC
  • 结合 GC 日志 的停顿与回收压力，选择合适的 GC（如 G1GC），并合理设置 -Xms/-Xmx；目标是降低 Full GC 频率与停顿时间，避免影响 p95/p99。
• 响应时间与网络
  • 在 Connector 启用 HTTP 压缩（如 compression=“on”），减少传输体积、缩短客户端感知时延；同时优化慢查询、缓存与静态资源处理链路。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！