After all of the connections, views, alarms, and filters are created, an application requests values for performance data. Retrieving performance data is a three-step process:
Refresh the data.
Check the row count.
Look at each data item in the view.
When a Monitor Client Library application needs to retrieve data, it initiates a refresh. The refresh causes Monitor Client Library to obtain fresh data. After each refresh, the application retrieves the data in each view on an item-by-item basis (that is, for each column of a table).
After calling smc_refresh_ex on a given connection, the application retrieves the data. The user retrieves data on an item-by-item basis.
Depending on the number of events being collected, frequent refreshes might be necessary. A view that contains many keys needs more frequent refreshes than views with one or a few keys. The following symptoms might indicate an application that is not refreshing frequently enough:
Very large numbers of lost events reported in the Monitor Server error log. The Sybase Adaptive Server Enterprise Monitor Server User’s Guide discusses configuration changes that can also help to reduce event loss.
The application appears to hang in a call to smc_refresh_ex. A large number of keys in a view can cause a condition in which Monitor Server can not keep up with the number of events being collected and does not return control. Because of this, Monitor Server begins to consume large amounts of CPU time.
smc_get_row_count determines how many rows of results are available for a view. A view returns results in what is essentially a table with potentially many “rows” of result data, but in some cases, possibly zero rows.
smc_get_dataitem_value retrieves performance data values for a single column of a single row of a view.
Filters and alarms are applied during the refresh of the data.
Polling for new performance data is client-driven and is limited only by the speed of the data-providing system and the data-gathering system.
See the code sample on page 26.
