Applications Manager Client Slow to Respond

Products

• CA Automic Applications Manager (AM)

Issue/Introduction

Applications Manager Client Slow to Respond

Environment

Release: Automic Applications Manager

Cause

The Client Request (CR) threads handle actions on the client that need to get or put data to or from the RmiServer.  Some of the threads are for refresh while others get job data when editing a job or any other action submitted by the client.  On some systems where a high volume of jobs are being submitted at one time, lots of users are logged in and doing things such as history filter queries, the client can become very slow to respond.

Troubleshooting

1) Enable RmiServer debugging and search for "elapsed ms" in the log.

2) Then search for the CR thread " CR".

3) If you find entries in the log for the Client Request thread (CR#) with a high elapsed time (anything over 30 seconds), this may indicate why the system is slow and you can take a look at what may be adding to the slowness by looking at what the CR threads are doing, see the example below.

---

Example

In an RmiServer debug log where a client thread was being used to process History Filter Queries that AM users are submitting from the so_job_history table that contained more than a million rows of data and where they were dumping a couple of thousand jobs into the backlog at the same time we saw that the Client Request thread was very slow (over 7 minutes (446226 ms) for one transaction).  Here are some examples of the lines from the RmiServer debug logs:

• .DBAccess: getSqlData(): sID-9267355 APPWORX query elapsed ms 191948 rows 4 SELECT DISTINCT * from AW_JH_VIEW WHERE 1 = 1  and (( chain in ('NIGHTLY_UPDATE') )  or ( ( so_module in ('NIGHTLY_UPDATE') ) and so_sched_flag = 'Y'))  AND  (so_job_finished BETWEEN TO_DATE('20XX-08-23 16:24:00','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('20XX-08-28 1
  6:24:00','YYYY-MM-DD HH24:MI:SS'))order by so_job_finished desc
• .DBAccess: getSqlData(): sID-9272344 APPWORX query elapsed ms 33158 rows 23 SELECT DISTINCT * from AW_JH_VIEW WHERE 1 = 1  and (( chain in ('DAILY_WTW_C') ) or ( ( so_module in ('DAILY_WTW_C') ) and so_sched_flag = 'Y'))  and ( so_job_finished >= TO_DATE('20XX-09-02 00:00:00','YYYY-MM-DD HH24:MI:SS'))order by so_job_finished desc
• .DBAccess: getSqlData(): sID-9272352 APPWORX query elapsed ms 446226 rows 0 SELECT DISTINCT * from AW_JH_VIEW WHERE 1 = 1  and ( requestor like 'NIGHT_REQUESTOR'  ) order by so_job_finished desc
• .DBAccess: getSqlData(): sID-9230950 APPWORX query elapsed ms 190586 rows 102 SELECT DISTINCT * from AW_JH_VIEW WHERE 1 = 1  and (( chain in ('MAINTENANCE_SYS') )  or ( ( so_module in ('MAINTENANCE_SYS') ) and so_sched_flag = 'Y'))  and ( so_job_finished >= TO_DATE('20XX-07-30 17:29:00','YYYY-MM-DD HH24:MI:SS'))order by so_job_finished desc

Resolution

In this particular case, our recommendation was to create Reports in Applications Manager to query the so_job_history table instead of doing History Filter Queries which because of other things they were doing at the same time caused their GUI to be extremely slow.