Version

All

Date

20 Aug 2010

Summary

When going from one XT product to another through the GUI, it may take upwards of 60 seconds, or sometimes even timeout.

Technical Background

The first suspect is the speed of the connection to the database.

When you go from one XT product to another, the following actually happens in the background:

* The names of all definitions in the various trees (Rules, Alerts, etc.) are loaded

* All data in the XX_JOBWATERMARK and XX_EXECJOBS tables are loaded

If the database connection is slow, or if the database server is heavily loaded — you won’t get the information returned in a timely manner.

However, sometimes it is not the fault of the database or its connection.

Loading the names of all definitions is fast — almost negligible, unless you have thousands of Relators or Monitoring Groups.

The tables that causes the most potential slowdown are the XX_JOBWATERMARK and XX_EXECJOBS tables.

These two tables hold the historical data for the History screens for each product (the XX differs based on the product code, e.g. AG = Argent Guardian).

These tables are automatically purged at service recycling time (e.g. midnight), so they start fresh each day.

For customers with a huge number of servers, and Relators with frequent schedules running all day, these two tables can fill up extremely quickly, causing a slowdown in the GUI.

You can check if this is the case by doing a SELECT * on both tables.

If the number of rows for each table exceeds 10,000 — this is considered excessive.

Resolution

If we have verified that the number of rows for the two tables are excessive, customers may opt to create a SQL Job to periodically purge information that is deemed outdated.

For example, to only keep Argent Guardian Relator task history for the past hour, you can configure the SQL Job to run this query:

Delete from AG_EXECJOBS where ExecuteTime < dateadd('minute', -60, getdate())