当你点了一个按钮，发现怎麽很久才出现结果，你可能会怀疑是不是 ZK 出了什麽问题？这是很直接的推断，但原因通常不一定是 ZK，因为毕竟 ZK 只是一层薄薄的 UI 层，触发 ajax request 後要透过网路传输，还会呼叫倾听器、执行业务逻辑、查询资料库等，牵扯甚多，很难一眼看穿问题根因。只因 UI 是表现程序速度慢的最明显特徵，因此常常被当作罪魁祸首，只能说「冤枉啊！大人！」。以下就提供简易初步判定方法来协助你找出效能瓶颈，以免错杀好人，纵放主嫌。

效能分析步骤

从 ZK 的架构来说，效能瓶颈可分为三类：

1. 浏览器端
   浏览器花很多时间绘制画面，有时是因为 DOM element 太多，画面变动需时较久，有时是因为 CSS 变动造成 reflow
2. 网路
   网速过慢造成资料传输时间很长
3. 服务器端
   服务器上的程序执行时间过长，原因非常多，倾听器逻辑很复杂、资料量大、查询资料库耗时、服务器硬碟读取时间过长都有可能

观察waiting time

一个快速简便的判断法是：

开启 developer tool > Network 页签，检查对应事件的 AU request 的 timing：

（有关 Timing 中各个期间的意义请看 Chrome 文件）

waiting time 过长

如果 waiting time 过长，瓶颈多半在「服务器端」，也就是服务器的程序码执行时间较长。另一个快速的判断方式是：观察是否出现 ZK 预设的「处理中」讯息

在 au request 发出之後 900ms ，如果没有收到服务器的回应，ZK 就会显示这个预设忙碌讯息，因此可以用来初步判定可能是服务器执行时间较久造成。

但是也有少数例外情形，就是万一服务器回传的内容造成 Javascript 执行错误，导致 ZK client 端程序停止，因而没有把「处理中」的讯息消除，让我们误以为是服务器执行很久尚无回应。不过这种情形很容易分辨，只要打开 developer tool > Console 页就会很快发现错误。因此比较谨慎的除错法还是观察 Timing。

效能分析器

当初步判断瓶颈为服务器端时，事情还没结束。如果按一个按钮触发倾听器，其中呼叫服务层、又呼叫了储存层去查资料库，牵涉的物件很多，很难直接判定到底是哪一层耗时最久，这时通常我们可以依靠效能分析工具来帮我们计算每个 method 所花的时间，这类工具很多，但最简便易得的就是 JDK 内建 Visual VM。

透过 Sampler 或 Profiler 都可以得知 hotspot （最耗时的 method），据此来判断瓶颈发生在哪。因为 sampler 是定期取样来侦测程序执行状态，虽然得出的结果比较概略，但是对程序执行的速度影响较小。 Profiler 启动时因为要修改 JVM 中载入的 bytecode就需要相当时间，因此要记得在 Settings 中指定测量少数特定 package ，不然光启动就要花好上好几分钟，而且你的程序执行速度也会被大大拖慢，但是它可以精准测量出每个 method 执行多久、被呼叫几次，根据此资料再检查对应的程序码就可以找出问题根因，有时候是一个 method 执行过久，也有时是一个 method 被呼叫过多次。

Visual VM 介绍文章可以参考「【Java VisualVM】使用 VisualVM 进行效能分析及调优」。

waiting time 很短

如果 waiting time 很短，但是画面绘制仍然超出预期的久，极可能瓶颈出在「浏览器端」。常见的徵兆是，你会看到「处理中」的讯息只出现一下子就消失，但是浏览器画面却卡住没回应。这时还是得透过浏览器的效能分析工具来判断倒底它在忙什麽。

开启 developer tool > Performance 页签，按左边的小圆球就开始记录，这时就赶紧重制效能问题，重制动作完成後就停止纪录，Chrome就会产生类似如下一份图表给你：

你可以根据 screenshot 来找出浏览起最忙、没回应的时间里，到底在执行哪段 JavaScript 来判定效能瓶颈。当然如果使用 ZK 多半出现 client 端效能瓶颈会出现在 ZK js widget 中。如果是如此，可将问题回报 http://tracker.zkoss.org/ 有时能够取得暂时性解法。

以上只是提供简单快速的分析法，详细的资讯请参考 Step by Step Trouble Shooting 。