Skip to content

项目实战

Redmine 性能监控与分析

学习体系

  • 掌握常见性能监控工具和平台的搭建
  • 掌握性能监控数据的采集与分析
  • 掌握性能瓶颈的分析与优化

知识模块

  • 性能监控体系 L1
  • 性能监控体系 L2

实战需求

业务部门需要对 Redmine 这个产品做压力测试。需要支持的用户量为 100，在并发的过程中用户主要的行为操作在：

  1. 登录。
  2. 创建 issue。
  3. 查询 issue。

实现思路

  1. 需要根据业务需求制定性能测试计划。
  2. 根据性能测试计划执行性能测试。
  3. 获取相关的监控数据，并分析压力瓶颈。

制定性能测试计划

目标
  • 测试 Redmine 在 200 个并发用户下的性能和稳定性。
  • 测量登录、创建问题和查询问题等关键用户操作的响应时间、吞吐量和错误率。
  • 识别任何性能瓶颈，并确保应用程序能够处理预期的用户负载。
测试环境
  • Redmine 版本: 5.1.0
  • 数据库: MariaDB 10.6.12
  • 服务器配置: 4 核 16G 内存
  • 网络: 10Mbps
测试场景
  • 登录 用户将使用 HTTP 基本认证登录。 每个用户将有唯一的凭据。
  • 创建issue 用户使用动态数据创建新issue。
  • 查询issue列表 用户查询项目的issue。
工具

JMeter 版本: 5.6.3

测试数据
用户凭据: 包含 200 个唯一用户凭据的 CSV 文件。
问题数据: 用于创建问题的动态数据。

编写性能测试的脚本

  • jmeter 录制
  • API 接口测试脚本编写

性能数据采集与监控

性能瓶颈分析

常规摸高测试和负载测试

  • 测试方法：

    • 使用 JMeter 进行常规摸高测试和负载测试，逐渐增加并发用户数，观察系统的性能表现。 初始并发用户数设置为 10，每隔 5 分钟增加 10 个用户，直到达到目标并发用户数 100。 测试结果：
    • 在 100 个并发用户时，系统响应时间逐渐变长，但仍在可接受范围内。
    • 达到 110 个并发用户时，系统开始出现明显的响应时间增加和错误率上升。
    • 在 200 个并发用户时，系统的响应时间显著增加，错误率明显上升，用户体验显著下降。
    瓶颈分析：Redmine 服务

    通过分析测试结果，发现当并发用户数接近 70 时，Redmine 服务的响应时间显著增加，错误率上升。此时，Redmine 服务成为系统的性能瓶颈。

  • 验证方法：

    • 检查 Redmine 服务的日志和监控数据，确认 Redmine 服务在高并发情况下的处理能力。 使用监控工具（如 Prometheus 和 Grafana）观察 Redmine 服务的 CPU、内存等资源使用情况。
    • 解决方案：
    • 增加 Redmine 实例的数量，通过负载均衡器（如 Nginx 或 Kubernetes Ingress）分担流量，减轻单个实例的压力。
    瓶颈分析：MariaDB 服务

    在增加 Redmine 实例数量后，重新进行压测，发现 MariaDB 服务成为新的性能瓶颈。此时，由于 MariaDB 的最大连接数限制为 10，无法满足高并发请求的需求。

  • 验证方法：

    • 检查 MariaDB 服务的连接数配置和监控数据，确认 MariaDB 服务在高并发情况下的连接数使用情况。 使用监控工具（如 Prometheus 和 Grafana）观察 MariaDB 服务的 CPU、内存、连接数等资源使用情况。
    • 解决方案：
    • 查看最大连接数配置，SHOW VARIABLES LIKE 'max_connections';。
    • 调整 MariaDB 的最大连接数配置，增加连接池大小，确保能够处理更多并发请求SET GLOBAL max_connections = xxx;。
    • 进一步优化数据库查询，减少数据库负载，提高响应速度。

总结

  • 在对 Redmine 进行性能测试和监控之后，通过对各项数据的分析，可以清晰地识别出系统的性能瓶颈，并给出相应的优化建议。
  • 通过数据库优化、系统资源优化，提升 Redmine 的性能和稳定性，确保在高并发用户下的良好表现。
  • 持续进行性能监控和优化，有助于及时发现并解决潜在的性能问题，保证系统的长久稳定运行。