Power Pivot

To investigate performance problems in WDK applications I typically use capabilities of com.documentum.web.env.IFormRenderListener interface, the code below demonstrates a basic idea – when page starts rendering I put date into form return value and when page rendering gets finished I gather and log required information:

 * @author Andrey B. Panfilov <andrew@panfilov.tel>
public class FormRenderLogger implements IFormRenderListener {


    public FormRenderLogger() {

    public void notifyFormRenderStart(Form form) {
        form.setReturnValue(FORM_RENDER_LOGGER_START_DATE, new Date());

    public void notifyFormRenderFinish(Form form) {
        Date startDate = (Date) form
        long diff = new Date().getTime() - startDate.getTime();
        String containerId = null;
        String componentId = null;
        ArgumentList initArgs = null;
        Context context = null;
        if (form instanceof Container) {
            containerId = ((Container) form).getId();
            componentId = ((Container) form).getContainedComponentId();
            initArgs = ((Container) form).getInitArgs();
            context = ((Container) form).getContext();
        } else if (form instanceof Component) {
            componentId = ((Component) form).getComponentId();
            initArgs = ((Component) form).getInitArgs();
            context = ((Component) form).getContext();
        String userName = null;
        try {
            if (ComponentDispatcher.isRepositoryAccessRequiredComponent(form
                    .getId())) {
                IDfSessionManager sessionManager = SessionManagerHttpBinding
                if (sessionManager != null
                        && SessionManagerHttpBinding.getCurrentDocbase() != null
                        && sessionManager.hasIdentity(SessionManagerHttpBinding
                        && form instanceof Component) {
                    userName = ((Component) form).getDfSession()
        } catch (DfException ex) {
            throw new WrapperRuntimeException(ex);
        StringBuilder message = new StringBuilder(50);
        if (containerId != null) {
            message.append("Container: ").append(containerId).append(", ");
        if (componentId != null) {
            message.append("Component: ").append(componentId).append(", ");
        if (userName != null) {
            message.append("User: ").append(userName).append(", ");
        if (initArgs != null) {
            message.append("InitArgs: ").append(initArgs).append(", ");
        if (context != null) {
            message.append("Context: ").append(context).append(", ");
        message.append("Remote IP: ")
                .append(", ");
        message.append("Render time: ").append(diff).append("ms");
        DfLogger.debug(this, message.toString().replaceAll("\\{", "[")
                .replaceAll("\\}", "]"), null, null);



<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <application extends="webtop/app.xml">

Something similar was described earlier by Stephane Marcon in Documentum Monitoring – platform logs’ centralization using Logfaces – Part 2, but the problem is logs accuracy of webtop logs collected by Stephane completely suck. Though, code, given above, does not provide information about delays caused by wdk actions, you can take advantage of IFormRenderListener, IApplicationListener and IRequestListener interfaces to implement more robust solution (see example of usage in Dynamic groups. Advances. Part IV).

But yesterday I have faced with a weird problem. Typically I parse performance logs into tab-delimited file, then load this file into excel and build some reports to figure out what wdk components are slow. But yesterday I have found that customer’s daily logs contain more than 3 million rows and Excel does not support such a amount of data. What to do? Power Pivot comes to the rescue!

5 thoughts on “Power Pivot

  1. Hi Andrey,

    Happy to see my logs completely suck, :-).

    For sure, there are WDK-native ways to actually get information about Webtop activity. In the case of a pure performance investigation the use of some request or form render listener definitely makes sense (I have a little doubt about the interest of the application listener here…).

    In the context of my sucking logs, (i.e. in a monitoring context), I wanted to have a single solution which would provide logs for Webtop but also any application (like the JMS) running on a servlet container. There is indeed a cost which comes with this flexibility.

    But actually, in the particular context of Webtop, your remark makes me think, it could indeed be interesting comparing the actual execution times given by a RequestListener implementation and a servlet filter one like the one I propose.

    In the context of a monitoring solution, it could be interesting to estimate/measure:
    – the actual execution time the use of a FormRenderListener would hide, considering it hides the execution time down to the form processor
    – the actual cost of the retrieval of the contextual information (username, ip (maybe getRemoteAddr() would be recommended in this context),…).



  2. Stephane,

    the question is not about performance (neither performance analysis nor filter’s performance). The question is about the accuracy of information being collected. When you’re gathering logs for stateless applications everything is OK – JMS demo in your post is awesome, but what information could be extracted from following webtop log:

    ? “User opened some grid and clicked checkout on the second row” – in my opinion this information is useless.


  3. OK, then I understand. And I agree that the accuracy is limited to the actual verbosity of the application at pure HTTP level. And the objectlist is indeed a pain. I still cannot find any tangible reason for this objects selection array design, especially on Webtop’s interface which makes such an intensive usage of JS… But I understand your point, and it could be a good idea to see what would be the cost (in terms of performance) of using either the RequestListener and/or the FormRenderListener VS the additional benefit.


  4. Pingback: Documentum Monitoring – platform logs’ centralization using Logfaces – Part 3 | Stephane Marcon´s Documentum Blog
  5. Pingback: Bulk fetches | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s