关于一个profiler工具的设计

我目前想对之前写的一个profiler工具进行重构，和大家探讨一下我设想的一些思路。

首先，在设计中包含一个重要的概念-----轨迹。

• 轨迹的设想
  

        1）轨迹的定义

        在系统中，任何程序的执行都有可能留下轨迹（数据库的调用会留下SQL轨迹，事务的轨迹，http请求会留下访问的轨迹，程序的方法执行也可以留下轨迹）。

        轨迹包含了对性能分析有用的信息（比如上下文的信息，线程堆栈的信息，执行时间的信息等等），轨迹之间存在关系，比如数据库事务的轨迹和SQL的轨迹，http请求和类方法执行的轨迹之间都有一定的关系。在性能分析中，我们可能存在几个关注点，比如数据库，远程调用，方法调用，组件等等，通过这些关注点相关程序留下的轨迹，我们进行性能分析。

        2）轨迹的管理

       轨迹是错综复杂的，零碎地，关系模糊的，所以要真正有助于性能分析，还需要相应的支持。所以，轨迹又需要生命周期管理，和统计管理。

       轨迹的生命周期管理：轨迹创建----到销毁的各个状态，有些时候,对于有问题的轨迹（比如执行时间过长），我们不希望销毁轨迹，我们把这部分轨迹保留下来供性能分析。

       轨迹的统计：不同关注点的轨迹，存在不同的统计逻辑，通过统计，展现给性能分析者，统计的逻辑可能很多样，组件必须保持这方面的扩展。

     3）轨迹的注入

      轨迹不会自己产生，我们也不可能修改系统的代码。而我又不想像其他的一些分析工具一样，通过本地接口获取JVM的状态从而进行统计（那样就得依赖JVM，依赖OS）。现在我唯一能想到的办法，是采用classworking。目前，我已经实现了一个ClassEnhancer，它能够对指定的类在现有ClassLoader模型采用父子委托模型的情况下很好的对类进行inject（如果不是这种模型，有可能在某些很特殊的部署方式下inject失败）。

• 组件的设计

     1）构件模型

      组件的内部构件包括：

     核心构件：包含轨迹，轨迹的生命周期，轨迹的统计

     bytecode构件：可以对类进行inject，采用最通用的代理模式invokehandle模式。

     各种监控的构件：依赖于核心构件（有可能也依赖于bytecode构件）构造各种监控构件，比如数据库监控构件，类方法监

控构件等等，构件可能扩展统计逻辑，现在对于这种构件还没有想好怎么样定义他们的统一行为，我希望以后可以再此基础上由第三方扩展新的监控构件。

     配置构件：没什么好说的。。。

     界面：目前我是采用servlet，不知道大家有没什么好建议，像现在其他的profiler似乎都采用swing，这样做似乎部署挺成

问题，我希望组件适用于生产环境，而不只是监控监控测试环境，那样分析不出什么，但是servlet做出来的界面效果。。。

    2）部署

    我希望部署越简单越好，现在我能够做到的配置，需要配置各种统计策略数据，但是数据库监控的数据配置比较繁琐，主要是由于，之前数据库监控构件不是基于classworking实现 ，而是采用代理连接池实现。不过现在可以通过classworking在数据库驱动这层进行注入。

 

     先写这么多，也算整理一下自己的思路，欢迎大家提出新的想法。

评论

12 楼 baixue7046 2008-04-29  

关注中....
我现在正在做关于基于构件的软件系统的集成测试问题,目前的思想是借助aop来做,跟你说的"轨迹"有点相似,希望交流

11 楼 javatar 2007-07-03  

sg552 写道

窃以为，这个东西一个人是搞不出来的。

互相帮助，就不只一个人了^_^

10 楼 sg552 2007-07-03  

祝福LZ好运气了。

窃以为，这个东西一个人是搞不出来的。

9 楼 leadyu 2007-07-02  

恩，谢谢javatar兄，这个东西只能算是一个实践，现在还很幼稚，不能和javatar兄的模版引擎相比，呵呵，完善它还有很长的路要走，主要是没有太多时间，毕竟养家糊口就够我累得了，^_^,不过我现在已经尽可能的抽时间来做。

之前不经意在javaeye上找到这么个群，还遇见了javatar兄这样的先驱者，非常好，以后这里会有更多的人，大家多多交流互相支持。

8 楼 javatar 2007-07-01  

Profiler比拼的就是信息的分析，一个只会把一大堆数据抛给用户的工具只能算玩具，Profiler应该足够AI，呵呵，相信你在方面能做的更好。第一个支持你。

7 楼 leadyu 2007-06-30  

这也正是我想追求的：

1）性能：不去尝试记录所有类的执行

2）过滤：根据分析条件过滤出有用的执行信息帮助性能分析，不要像很多profiler工具把整个jvm细节暴露给你

3）开源：没有任何的licence限制，现在比较出名的profiler工具不是商业的就是限制商业使用的open source

4)平台移植性：纯JAVA，不依赖JVM和OS，否则组件的生命会很脆弱，使用的时候也会很麻烦，我希望组件是使用在生产环境，而不是测试环境。

另外，我还想补充的是：

1）部署方便：希望是非常的方便，不要企图以自己的类启动应用，也不要企图配置远程端口来实现视图，我希望就是通过几行的配置文件就能完成部署。

6 楼 leadyu 2007-06-30  

转〉The ideal profiler

Like selecting any other tool, selecting a profiler involves trade-offs. Free tools like hprof are easy to use, but they have limitations, such as the inability to filter out classes or packages from the profile. Commercial tools offer more features but can be expensive and have restrictive licensing terms. Some profilers require that you launch the application through the profiler, which means reconstructing your execution environment in terms of an unfamiliar tool. Picking a profiler involves compromises, so what should an ideal profiler look like? Here's a short list of the features you might look for:

Speed: Profiling can be painfully slow. But you can speed things up by using a profiler that doesn't automatically profile every class.


Interactivity: The more interaction your profiler allows, the more you can fine-tune the information you get from it. For example, being able to turn the profiler on and off at run time helps you avoid measuring class loading, compilation, and interpreted execution (pre-JIT) times.


Filtering: Filtering by class or package lets you focus on the problem at hand, rather than being overwhelmed by too much information.


100% Pure Java code: Most profilers require native libraries, which limits the number of platforms that you can use them on. An ideal profiler wouldn't require the use of native libraries.


Open source: Open source tools typically let you get up and running quickly, while avoiding the restrictions of commercial licenses.

5 楼 leadyu 2007-06-29  

引用

生命周期管理可以使用Observer模式，

这点我赞同，可以由生命周期管理器发起事件，各种分析器作为观察者。

4 楼 leadyu 2007-06-29  

恩，我考虑考虑，现在数据库监控已经不用jdbc proxy了，直接通过bytecode inject驱动程序来的简单，比如inject：oracle.jdbc.OracleDriver

3 楼 javatar 2007-06-29  

生命周期管理可以使用Observer模式，
也就是事件监听机制，以事件驱动。
这样方便第三方组件需要引用生命周期时，可以很方便的插入。

2 楼 javatar 2007-06-29  

轨迹的收集与分析应该分离，可以使用Builder模式，
收集器作为Director，可以从不同地方收集数据，如:bytecode interceptor，jdbc proxy等;
分析器作为Builder，可以产不同的输出，如：图，xml等等。

1 楼 leadyu 2007-06-28  

继续写。。。

上面只是简单讲了下目前的思路，下面我有一些问题没有解决，大家有没什么好的想法：

1）对于轨迹的生命周期管理
我现在想到的轨迹生命周期，包括：创建，执行开始，执行结束，销毁。对于这块的管理，有没什么优秀的模式可以借鉴？

2）对于轨迹的统计策略，现在我只实现了根据执行时间进行过滤得策略，那么这种策略可能根据性能分析的角度不同而改变，怎么抽象这种策略？

3）现在轨迹的展现，我采用servlet来做，这样的好处就是部署简单，但是坏处就是视图单一，起码没有jprofiler好看。而且轨迹是暂放在生命周期管理器中，由它维护一定量的轨迹和进行回收。

4）现在我已经做了数据库，http请求，类方法执行3个角度的监控，功能相对比较实用和丰富，但是还有其他对性能分析有帮助的功能吗？

欢迎大家提出意见。