vlambda博客
学习文章列表

目前我们所接触到的系统绝大部分的还是使用Java开发的，因此针对于Java类系统的监控分析需求较大，Java类系统开发依赖的JDK非为常用的两类Sun-JDK和IBM-JDK，大部分的开源工具只是针对于Sun-JDK的，例如本章所讲的Glowroot。

一、简介

Glowroot是一个快速，干净和简单的APM工具。它可以跟踪捕获缓慢的请求和错误，能够记录每个用户的操作时间，以及SQL捕获和聚合。该工具还可保留汇总所有历史数据。

　　它通过图表的方式显示响应时间分布和响应时间百分比，并允许用户通过移动设备监控应用程序性能。

二、Glowroot的使用

2、在启动java程序时加上参数 -javaagent:path/to/glowroot.jar；例如使用的是tomcat的话，在tomcat启动文件中增加以上参数后，重启tomcat。 

3、服务启动之后，确定4000端口启动后，在本地的浏览器中访问 http://localhost:4000就能看到分析界面了（将localhost更换成要监控被测系统的服务器IP）。

一旦工具启动并运行，你将获得能够设置响应时间百分比和MBean属性的警报。Glowroot提供对跨多线程异步请求的全面支持，支持Tomcat，TomEE，JBoss EAP，Wildfly，Jetty和Glassfish等服务器。

三、使用Glowroot监控优化案例

场景：首页接口，涉及的信息有用户信息、可兑换奖品信息、任务列表信息，在高并发的情况下，就会出现性能问题。

2.1 优化之前

1. 调用图分析

[通过jmeter 200 并发的场景下，glowroot工具反馈出的调用图]:

    最左边是一开始的压测图，可以看到jdbc获取连接的时间占用了很大的比例，很明显的连接不够的原因，查看配置文件发现连接只有 5 个，redis连接也只有 10个，配置上之后重新压测结果就是中间的图样，这时瓶颈在jdbc和代码处理了。

1. 最左边是一开始的压测图，可以看到jdbc获取连接的时间占用了很大的比例，很明显的连接不够的原因，查看配置文件发现连接只有 5 个，redis连接也只有 10个，配置上之后重新压测结果就是中间的图样，这时瓶颈在jdbc和代码处理了。

2. sql调用分析

    优化1 : 从图表可看出，兑换奖品表有八千多次查询量，原因①是目前测试环境需要关闭配置隔天生效的设置，每次查询直接查DB，原因②首页的奖品库存需要实时展示，每个用户都会去查询，导致sql调用量增高，可以优化成：从缓存中获取实时库存，定时任务每隔一秒去刷新最新的 数据到缓存中即可，在 1000QPS的场景下，优势就明显多了，原本每秒需要1000次sql查询就缩短成每秒 1次sql查询了。

  优化2：有些表的查询语句，都是同个用户id下进行，不过在不同层调用，这时可以统一优化，上层查询传递到下一层，实现减少调用量的目的。

2.2 第一次优化

1. 调用图分析

    优化效果比较明显，目前只是将兑换奖品缓存规则设置回来还有就是库存实时使用定时任务的方式，db的连接显然减少了一些，不过这时能看到redis的调用时间占比居然很明显，多时达到了几十毫秒，原因可能是项目设置redis连接数不足，或者是该接口对redis操作很频繁。

2. sql调用分析

    可以看到原先兑换奖品现在的查询数量已经降低了很多了，从业务方面也能接受一秒更新一次显示的库存。

四、资源

以下为Glowroot的官方学习资料和实例。

https://glowroot.org/

https://demo.glowroot.org/transaction/average?transaction-type=Web

部分内容原文链接https://blog.csdn.net/larva_s/java/article/details/88876451