背景

• 分析性能问题的难点
  • 无法直接在客户环境，获得量化的性能数据。
  • 本部可能无法重现问题。
  • 回传环境过程缓慢，由于客户的安全限制，甚至可能无法回传。
  • 受限于环境因素，客户回传的Portal可能仍然无法重现问题。

  综上因素，导致性能问题的处理时间，大部分消耗在了问题重现及环境搭建上。因此U9 自己开发的一个效率分析工具，包含对代码执行方法、调用 堆 栈 及 SQL 的 抓 取 及 时 间 统 计 。 

UMTracer的能力

• 监听本地发出的Http请求，并可获取请求的如下信息：
  • Http请求信息，包括耗时及请求上下行数据。
  • 监控方法的执行情况。
  • 监控SQL的执行情况。
• 开发人员，可以调用UMTracer服务端接口，进行自己的代码监控。

CodeProfiler.BeginExecute/EndExecute

SQLProfiler.BeginExecute/EndExecute

Code Profiler工具的特点是监控所有方法，分析时可以逐层展开确定最底层开销，UMTracer是更轻量级的核心方法调用监控，所以分析关注点也有所不同，建议关注：

• 关注开销分布，Method/SQL的开销比例。
• 对于SQL较高的案例，分析SQL执行时间及频度，并关注返回结果数。
•  对于Method较高的案例，关注调用逻辑合理性，以及重点方法的调用频度

简单说，UMTracer集成了Fiddler，SqlProfiler和AQTime的核心功能。

获取路径

在 U9 及 U9CE 安 装 时 会 自 带 ， 默 认 路 径 是  yonyou/U9CE/Portal/Tools/UMTracer New.zip。此工具直接在客户端使用，不必非要连接服务器。

最新版本工具请前往U9Hub下载：https://u9hub.diwork.com/a/tools/down

使用介绍

配置及登录

由于UMTracer 有过改版因此分为两种配置/登录方式

老版本需要在工具-配置打开配置窗体进行配置，将 pt09 替换为服务器 IP，U9 代表的是版本，如果是 U9CE 那么要改为 U9C

新版本需要输入 URL，然后通过用户账号进行登录。登录后可以在工具-重新登录

启动及监听

启动

登录后再次点击启动控制台，其中开启详细跟踪是会抓取方法的调用堆栈，开启秒 表是控制台秒表启动，并不是勾选开启秒表才会记录时间。

监听

打开控制后会悬浮在最上层，此时需要打开 U9找到动作慢的界面，数据准 备不要一次执行太多，由于这个工具在收集四分钟时可能就解析不出来了。再有就 是使用这个工具由于在收集数据因此会导致当前操作慢一些，如客户说更慢了可以 向其说明。监测时先点击开始，等操作完成后点击结束，等待分析即可。

结果导出

如要多次监测，那么需要先导出监测结果

然后再将监测结果删除

然后在工具-重新登录，然后再次启动控制台

监测结果

分析完成后会出现监测结果，选择耗时最长的查看性能分析，此时可以清楚的看到 SQL 的占比，如果 SQL 占比很高可以去查看是否可以优化 SQL，或添加索引。

选中耗时的方法后下方会出现对应的方法调用过程，并且会出现每一步的耗时

如图记录了多个插入后事件耗时，此时可以统计这个方法的总体耗时，通过统计可 以得到方法的总耗时，从而确认那个方法最耗时。

从上到下查看相同的方法占时是否逐步增加，如果逐步增加那么需要查看方法每次 执行时执行的过程是否一致，如不一致那么要确认是否因为不一致的点导致的耗时 增加。如一致那么需要考虑是否可以减少方法的调用，如通过增加全局变量或线程 缓存。

 查看耗时方法中那一步耗时需要再次展开，如图可以看到 Session.Commit 耗时， commit 要走 BE，调用过程为 OnSetDefaultValue-OnValidate-OnInserting/OnUpdating/ OnDeleting

知道耗时方法可以通过查看附加信息来在哪里调用的，如图可以看出是 
IssueDoc.UpdatePickIssueQtyWhenCreatDoc 方法中调用的 Commit。此时就需要查看 具体的代码查看是进行了什么处理，看是否可以进行优化，如单个提交的是否可以 改为一起提交，订单行上 OnInserted/OnUpdated/OnDeleted 单独提交的是否可以改 
 要一起讨论！

在 SQL 视图中可以查看 SQL，通过对 SQL 排序可以找到耗时最大的 SQL，或找出执 行次数较多的 SQL，通过 SQL 可以找到对应的方法，找到对应的方法查看堆栈信息 然后查看具体代码调用是否可优化