Profiler version 1.2

May 24, 2007 at 9:06 pm | Posted in Performance, Troubleshooting, Xense Profiler | Leave a comment

Isn’t debugging fun? Just spent the last few hours digging around the Xense Profiler code trying to track down an irritating bug where the text of some of the APIs and queries is missing from the profile report. Finally tracked it down and the v1.2 maintenance release is now available from the Xense Profiler page.

Hopefully I shall have some time to start adding some of the really cool features that I have been planning. I’ll keep this blog updated with the progress.

Performance Analysis of DMCL Trace Files

May 11, 2007 at 3:48 pm | Posted in Performance, Troubleshooting, Xense Profiler | 2 Comments

A couple of weeks ago I was investigating a slow running application. As usual I started a dmcl trace to work out where the performance problem was occurring. The largest API time was the following:

# [ 712 ] Thu Apr 12 15:45:58 2007 109000 ( 0.000 sec) ( 69 rpc) API> next,s0,q1
# [ 712 ] Thu Apr 12 15:45:58 2007 109000 ( 0.000 sec) ( 69 rpc) Server RPC: MultiNext (17)
# [ 712 ] Thu Apr 12 15:46:01 2007 203000 ( 3.094 sec) ( 70 rpc) Res: 'OK'

This trace excerpt indicates that:

  1. a ‘next’ api call took 3.094 seconds to complete
  2. The session involved was s0
  3. The next call was on a collection called q1

The next api is simply a call to retrieve the next row from a collection; in this case the collection is q1. Usually this collection originates from a query although certain other API calls also return collections, most notably the apply api to run an administration method.

So to find out which query is causing the performance problem we would have to search backwards in the trace file to find the last API that returned a collection q1 on session s0. This is all rather messy and if you have a large trace file (perhaps generated from a WDK application with a large numbers of users) rather error prone.

Luckily this work is automated by the Xense Profiler, a Windows command-line tool that takes a DMCL trace file as input and generates a performance profile report. For example if my trace file is called api.log then the following command creates a HTML report:

dmclprof api.log api.htm

If you view the report in your browser you will see a number of sections including a Top 10 API calls and a query summary. The Top 10 API Calls looks like this:

Duration
secs		 API Text
3.094 next,s0,q1
0.594 query_cmd,s0,T,F,,,,,select r_object_id from dm_document where folder(‘/WebPublisher Configuration/Content Templates’,descend) OR folder(‘/WebPublisher Configuration/Supporting Templates’,descend)
0.157 next,s0,q1
0.156 execquery,s0,1,select sysobj.r_object_id from dm_dbo.dm_webc_8009c009_s actv, dm_sysobject sysobj WHERE actv.r_object_id = sysobj.r_object_id AND sysobj.r_modify_date > DATE (’01/01/1970 00:00:01′) AND sysobj.r_modify_date
0.156 query_cmd,s1,T,F,,,,,select r_object_id, i_folder_id,r_modify_date, object_name, title from dm_category where r_modify_date > DATE(’01/01/1970 00:00:01′) AND r_modify_date
0.125 connect,dm3,dmadmin,xxxxxxxx
0.109 execquery,s0,1,select sysobj.r_object_id from dm_dbo.dm_webc_8009c009_s actv, dm_sysobject sysobj WHERE actv.r_object_id = sysobj.r_object_id AND sysobj.r_modify_date > DATE (’01/01/1970 00:00:01′) AND sysobj.r_modify_date
0.078 connect,dm3,dmadmin,xxxxxxxx
0.063 query_cmd,s0,T,F,,,,,select r_object_id, i_folder_id,r_modify_date, object_name, title from dm_category where r_modify_date > DATE(’01/01/1970 00:00:01′) AND r_modify_date
0.047 fetch,s0,090000038000f29a,,F

Here you can see the next API is the longest running call in the trace. Looking at the Query Summary report however shows all the queries that have been run in the system and provides a total elapsed time for each query – the total elapsed time for a query includes the time to run all the next APIs as well as the initial query call. The one that stands out is:

3.875  select r_object_id from dm_document where folder(‘/WebPublisher Configuration/Content Templates’,descend) OR folder(‘/WebPublisher Configuration/Supporting Templates’,descend)

Having identified the culprit we can now start remedial action.

Before we developed the Xense Profiler analysing DMCL traces could be a time-consuming and frustrating business. Using the Xense Profiler I can pinpoint the performance problem in minutes.

By the way although the tool runs on Windows it will accept a DMCL trace generated on any platform. I am planning to provide a Java-based port of the tool, if you are interested in hearing more about this then drop me a mail at robin.east@xense.co.uk.

Troubleshooting with IAPI

May 9, 2007 at 10:29 pm | Posted in Troubleshooting | 2 Comments

IAPI stands for the Interactive API interface, a command line utility for submitting Documentum API calls to the server. IAPI is part of the Unix Content Server installation. On Windows it is called IAPI32 – presumably the extra ’32’ is a reference to the 32-bit windows platform; I guess the original 16-bit Windows implementation was called IAPI but that was before my time!

Since the API is the lowest level interface to the Content Server IAPI is a great tool for troubleshooting when you want to cut the higher-level interfaces out of the equation. Normally you run IAPI directly on the Content Server machine, however there are circumstances where you are able to successfully test functionality on the Content Server but access from other machines (like WDK running on a remote application server) is still failing.

In this case it is often not clear whether the problem is with the DMCL layer on the app server trying to connect to the content server or maybe a problem higher up in the ‘stack’. One quick way to confirm whether the problem exists at the (remote) DMCL layer is to copy iapi/iapi32.exe plus the corresponding DMCL shared library (dmcl40.so or dmcl40.dll) to the App server and then test the remote DMCL by running IAPI remotely.

However there is a problem if your remote DMCL is running on a different platform from the Content Server (e.g. app server is on windows and the app server is on Solaris) as IAPI will only run on the platform it was compiled for. In this case you should be able to download the corresponding Content Server installation and extract the required files.

It would be great if Documentum would make IAPI/IAPI32 generally available as a separate download. On a similar note Documentum 6 is likely to remove the need for a separate DMCL shared library by moving all the DMCL code into the DFC java layer. Will they be providing a similar tool that allows simple low level API tests? I hope so.

Blog at WordPress.com.
Entries and comments feeds.