jsf-2 - 在服务器请求后测量JSF View 的渲染时间

Question

我想测量一个JSF应用程序的渲染时间。由于我的能力原因，无法在应用程序中填充日志。

因此，我的问题是，在使用任何浏览器执行包含后端(服务器)调用的特定操作之后，有什么方法可以衡量应用程序的渲染时间？

到目前为止，在使用Chrome开发者工具后，我发现了以下内容。在“网络”选项卡上，每个请求均显示“时间”。此外，选择某个条目后，在“时间”选项卡上，将显示更详细的可视化。
现在，我可以说“等待”是在这里捕获到服务器的往返，但是实际的渲染时间呢。

假设整个请求花了1秒，而“等待”部分是500毫秒，我是否可以推断出渲染时间是1秒钟-500毫秒？我不这么认为，这就是为什么我要问这个问题。

长话短说，对于某些请求，我需要从浏览器中知道，服务器处理了多长时间，实际的UI渲染了多长时间。

任何提示将非常感谢。谢谢你。

Answer 1

您可以使用自定义 ViewDeclarationLanguage 进行此操作，从而测量 createView() ， buildView() ， renderView() 以及必要时的 restoreView() 方法。

这是一个启动示例:

public class VdlLogger extends ViewDeclarationLanguageWrapper {

    private static final Logger logger = Logger.getLogger(VdlLoggerFactory.class.getName());

    private ViewDeclarationLanguage wrapped;

    public VdlLogger(ViewDeclarationLanguage wrapped) {
        this.wrapped = wrapped;
    }

    @Override
    public UIViewRoot createView(FacesContext context, String viewId) {
        long start = System.nanoTime();
        UIViewRoot view = super.createView(context, viewId);
        long end = System.nanoTime();
        logger.info(String.format("create %s: %.6fms", viewId, (end - start) / 1e6));
        return view;
    }

    @Override
    public void buildView(FacesContext context, UIViewRoot view) throws IOException {
        long start = System.nanoTime();
        super.buildView(context, view);
        long end = System.nanoTime();
        logger.info(String.format("build %s: %.6fms", view.getViewId(), (end - start) / 1e6));
    }

    @Override
    public void renderView(FacesContext context, UIViewRoot view) throws IOException {
        long start = System.nanoTime();
        super.renderView(context, view);
        long end = System.nanoTime();
        logger.info(String.format("render %s: %.6fms", view.getViewId(), (end - start) / 1e6));
    }

    @Override
    public ViewDeclarationLanguage getWrapped() {
        return wrapped;
    }

}

要使其运行，请创建以下工厂:

public class VdlLoggerFactory extends ViewDeclarationLanguageFactory {

    private ViewDeclarationLanguageFactory wrapped;

    public VdlLoggerFactory(ViewDeclarationLanguageFactory wrapped) {
        this.wrapped = wrapped;
    }

    @Override
    public ViewDeclarationLanguage getViewDeclarationLanguage(String viewId) {
        return new VdlLogger(wrapped.getViewDeclarationLanguage(viewId));
    }

    @Override
    public ViewDeclarationLanguageFactory getWrapped() {
        return wrapped;
    }

}

并在 faces-config.xml中注册如下:

<factory>
    <view-declaration-language-factory>com.example.VdlLoggerFactory</view-declaration-language-factory>
</factory>

createView()是基于 View 文件中存在的 UIViewRoot和 <f:view>创建具体 <f:metadata>实例的步骤。当使用Facelets(XHTML)作为 View 时，在此步骤中，所有关联的XHTML文件将由SAX解析器解析并缓存一段时间，如 javax.faces.FACELETS_REFRESH_PERIOD所定义。因此，可能发生的是，它的时间相对较慢，而另一时间却很快。
buildView()是基于 View (XHTML)组成填充JSF组件树( getChildren()的 UIViewRoot)的步骤。在此步骤中，将执行所有标记处理程序(JSTL和好友)，并评估这些标记处理程序中的所有EL表达式以及组件的 id和 binding属性(有关详细信息，另请参见 JSTL in JSF2 Facelets... makes sense?)。因此，如果在 View 构建期间第一次构造了支持bean，并在 @PostConstruct期间调用了业务逻辑，那么可能会很费时。
renderView()是从 UIViewRoot#encodeAll()开始基于JSF组件树和模型生成HTML输出的步骤。因此，如果在 View 渲染期间第一次构造支持bean，并在 @PostConstruct期间调用业务逻辑，则可能会浪费时间。

如果支持bean在getter方法中而不是 @PostConstruct或任何其他一次性发生的生命周期事件监听器中错误地执行业务逻辑，则可能会浪费更多时间。另请参见 Why JSF calls getters multiple times。