Performance Tuning for Content Manager

352 Performance Tuning for Content Manager

12.3 Slow logon

When users log on to the Windows client, eClient, or their own custom Content

Manager client (using Information Integrator for Content APIs), they might

experience slow performance. For example, in one scenario, users need

approximately 40 seconds to log on to the eClient. Some possible causes are:

 Slow DB2 UDB connection between client and server machines.

 Slow response from the LDAP server (such as the Microsoft Active

Directory® Server and IBM Tivoli Directory Server) if you enabled Content

Manager with the LDAP server.

 Slow response from DNS or network.

 A DB2 UDB performance issue.

 Slow response from Content Manager’s stored procedure call (such as

ICMLOGON), especially with some bad performance SQL statements.

Before we discuss these possibilities, we briefly explain the logon process.

Figure 12-1 illustrates the logon process. Content Manager clients are based on

the Information Integrator for Content APIs. When a user tries to log on to the

Content Manager client, the client calls the Information Integrator for Content

APIs. The APIs then talk to the DB2 UDB Client, which then calls the stored

procedures (such as ICMLOGON) on the DB2 UDB server. If you integrate

Content Manager with the LDAP servers, the ICMLOGON calls a user exit first to

authenticate the user ID and password with the LDAP server. If the LDAP server

cannot verify this user ID and password, the ICMLOGON stored procedure will

check it by itself. The logon process is also doing other jobs, such as getting item

type information from the Library Server.

Figure 12-1 Logon process

Content Manager Clients

II for Content application

II for Content API

DB2 UDB Client

Client Side

Network

db2fmp process

DB2 UDB Engine

Library Server Stored

procedures and UDF

LDAP Server

User

Exit

Server Side

Chapter 12. Troubleshooting performance problems 353

Content Manager consists of stored procedures and UDFs, so before the

Information Integrator for Content API can call the stored procedures, the API

must connect successfully to the Library Server database.

Whatever the cause, we need to check the ICMSERVER.LOG with level 15,

which can tell us which is used most of the time: the stored procedure call or the

user exit calls (including the LDAP server).

The Library Server performance trace can be controlled from the Content

Manager system administration client. Starting or stopping this trace will begin

immediately.

The Library Server performance trace can also be started and stopped from the

following script:

db2 connect to ICMNLSDB user icmadmin using <password>

db2 update icmstsyscontrol set tracelevel=15

db2 connect reset

Trace data will go into the file specified in the system administration client (called

ICMSERVER.LOG by default). To turn off the trace, run the following script:

db2 connect to icmnlsdb user icmadmin using <password>

db2 update icmstsyscontrol set tracelevel=0

db2 connect reset

This setting is applicable for all Library Server actions including search and import.

Example 12-1 shows sample output of the Library Server log with trace level 15.

Example 12-1 ICMSERVER.LOG sample content

ICMPLSLG ICMLOGON 01856 05/30 17:39:24.193 GMT ; ... ICMADMIN 1804 msec

...

ICMPLSMM ICMLISTMIMETYPE 00259 05/30 17:39:24.704 GMT ; ... ICMADMIN 266 msec

...

ICMPLSGA ICMGETATTRTYPE 00412 05/30 17:39:25.024 GMT ; ... ICMADMIN 240 msec

...

ICMPLSGT ICMGETITEMTYPE 00919 05/30 17:39:28.489 GMT ; ... ICMADMIN 3404

msec

The second field is the name of the Library Server operation, and you can find

the times spent on the operation in milliseconds in the end of the row. This

information shows whether a performance issue is due to time spent within the

Library Server or some other component of the Content Manager system.

Note: Trace level 8 is for performance, but trace level 15 can give us

information besides performance.