1. 页面加载慢

页面加载慢时，可在浏览器上按F12按键唤出调试页面，下图以Chrome为例说明排查方法：

浏览器查看

• 查看Network标签可排查页面慢的问题
• 观察Time列，是否有耗时很久的API
• 也可观察Waterfall列，直观的看到耗时久的API，水平绿柱（或蓝柱）越长则耗时越久
• 鼠标悬停瀑布图的某个水平柱上，可显示详情，一般关注Wating和Content Download两项
  • 前者一般可表示服务端API耗时
  • 后者表示从API首个回复包到最后一个包的时间，通常可结合表格中的Size列，内容越大传输越耗时

一般可将上图截图给后端支持人员，注意也需要包含第一列（API信息）。

注意：要先打开F12调试框，再刷新页面才能查看到API调用信息。一般可以在打开F12后切换一下菜单，然后点击上图中左上角第二行、第二列的清除图标，然后再切回需要排查问题的菜单来查看。

2. 排查全景图API响应慢

对于全景图API，还可通过子视图的查看API功能，或Kibana APM功能排查性能瓶颈。全景图流量搜索（除流量日志以外）会依次调用statistics、clickhouse进程完成一次页面的API请求。

2.1 通过API返回信息排查

每个子视图右上角的标准操作（齿轮）中，都有查看API的操作。点击后弹出框如下图所示：

API-第一步

在弹出页面中点击POST，可向控制器发送请求，之后点击页面中的回复显示可查看如上图所示的API返回信息：

• 返回信息中的_QUERY_IDS列出了控制器statistics调用clickhouse的API请求，及每个请求对应的含义
• 返回信息中的_TSDB_INFO为上述对clickhouse的多个请求的详细信息，请求顺序与_QUERY_IDS中一一对应
  • 红框中的最上方的QUERY_TIME（4）：表示statistics进程响应此次API请求的总耗时
  • QUERIES中的每个QUERY_TIME（5）：表示statistics每次查询clickhouse的耗时
  • NODES中每个IP（6）：IP表示一个数据节点，其后的数值代表该数据节点所在区域的clickhouse集群查询耗时

一般而言，可基于上述信息按下面的方法判断性能瓶颈：

• 若（6）显著大，说明某个区域的clickhouse处理慢
• 若（5）显著大，说明某个statistics的子查询慢，一般是clickhouse处理慢
• 若（4）显著大，说明statistics处理慢

2.2 通过Kibana APM排查

除了通过DeepFlow页面的查看API功能排查单次API调用的性能瓶颈以外，statistics内部使用OpenTracing框架进行了性能监控，可通过Kibana页面查看性能瓶颈。

访问方式：通过DeepFlow页面右上角的外部链接中Kibana访问，也可直接访问https://${DeepFlow主控制器IP或域名}/kibana/。页面如下图所示：

APM-第一步

点击上图左侧的APM，然后点击右边的statistics，可以进入查看statistics的应用性能链路追踪数据。

在statistics页面中，可通过右上角时间控件修改时间范围，页面下方的表格默认按延时从大大小对API进行了排序，点击需要排查的API进入特定API的监控页面：

APM-第二步

在该详情页面中，下图的柱状图表示该API的时延分布，可以选择查看具体时延范围的链路追踪图。下方的链路追踪图用不同的颜色标识了不同的函数或服务，并且通过瀑布图的方式展示了API调用过程的耗时。直观的来看，某个水平柱状图越长代表对应服务的耗时越大，此时如果它的下方还有耗时很长的柱那么可以沿着它继续寻找瓶颈，否则它本身对应的服务就是性能瓶颈所在。

APM-第三步