Performance Tuning for Content Manager

Chapter 12. Troubleshooting performance problems 365

system. A bad Windows client means that the user experiences a performance

issue when logging on to the Content Manager. We discover that ICMADMIN

experienced the same performance issue on bad Windows client machines. We

concluded that the issue should not be on the Content Manager server side; it is

not related to the specific user IDs.

Same Windows client and DB2 Client software?

We check to see whether the clients are using the same fix pack level for the

Windows client and DB2 client software. In this scenario, both the Windows client

and DB2 client software are at the same fix pack level for the good and bad

clients. This removed the possibility that the software itself was the cause.

Different locations?

We check to see whether the bad Windows clients and good Windows client are

on different sites or different networks. We discover that the clients are physically

located in different cities and all bad performances were from two cities. Now, we

suspect it is a network or firewall issue.

Network/firewall issue?

We work with the network and the firewall administrator to trace the network and

firewall. We finally determine that a network caused the performance issue.

12.3.4 LDAP/DNS server issue

If you integrated Content Manager with LDAP, the ICMLOGON would call a user

exit to authenticate a user ID and password with the LDAP server. Sometimes,

the slow logon can be caused by one of the following reasons:

 The LDAP server responded slowly.

 DNS resolved the host name of LDAP server slowly.

 The network between Content Manager and LDAP server had performance

issues.

The Library Server log file can tell us:

 When the user exit sent the authentication request to the LDAP server.

 When the user exit got the reply from the LDAP server.

 Whether the LDAP server authenticated the user ID and password

successfully.

Based on the two timestamps mentioned above, we calculate how long the user

exit talks to the LDAP server.

366 Performance Tuning for Content Manager

In one scenario, a Content Manager system is integrated with eight LDAP

servers using a virtual host name. This virtual host name was resolved to eight

different LDAP servers in different cities by a DNS server. There is an intermittent

logon performance issue. We set the trace level to 15. Some of the extracted

information from the ICMSERVER.LOG file is shown in Example 12-11.

Example 12-11 ICMSERVER.LOG with LDAP/DNS server issue

ICMPLSLG ICMLOGON 00764 12/16 17:43:12.286 GMT ;16174312286387

30739437893591544842 TA012005 Input

UserID <TA012005>

DB2UserID <CMCONCT>

Language < >

Application <ICM Connector>

……

ICMPLSLG callUserExit 02024 12/16 17:43:12.287 GMT ;16174312286387

30739437893591544842 TA012005 ICMLogExit input

ICMPLSLG callUserExit 04026 12/16 17:44:29.153 GMT ;16174312286387

30739437893591544842 TA012005 Closing Library...

ICMPLSLG callUserExit 02066 12/16 17:44:29.154 GMT ;16174312286387

30739437893591544842 TA012005 User Exit returned

RC 0

Reason 1

ExtRC 0

ExtReason 0

……

ICMPLSLG ICMLOGON 01825 12/16 17:44:29.155 GMT ;16174312286387

30739437893591544842 TA012005 76871 msec

ICMPLSLG ICMLOGON 01826 12/16 17:44:29.155 GMT ;16174312286387

30739437893591544842 TA012005 Exit rc=0 reason=0 extrc=0 extreason=0

We found that:

 TA012005 user ID used 76.8 seconds to login the system.

 The Content Manager server sent the LDAP authentication request out at

17:43:12 and got the reply at 17:44:29.This action used 76 seconds.

Thus, almost all of time is spent on talking to LDAP server to verify the user ID.

We thought either one of the following situations might happened:

 One of the LDAP servers delayed the entire authentication process.

 The DNS server/network between the Content Manager server and the LDAP

server delayed the entire authentication process.

Working with the LDAP server administrator, the LDAP server looked fine. We did

an IP trace on the network. Later on, we discovered that there was a

configuration issue in the DNS server.