The strategy that the AppManager ResponseTime modules deploy for measuring network and server response time and availability is based on synthetic network transactions.
Whenever you run a job using one of the ResponseTime Knowledge Scripts, a software agent performs a transaction involving the real application server you want to test. Transactions performed for response-time testing are “synthetic” only in the sense that no actual user is involved—the transactions are performed purely in order to monitor performance and availability.
The ResponseTime modules all rely on unique technology developed by NetIQ for monitoring system performance at the application layer. So you not only find out how well the system is performing; you also find out how well SQL Server or Outlook transactions in particular are performing.
Most AppManager ResponseTime modules have two parts:
A shared managed object component, QCMA.dll, installed in NetIQ\AppManager\bin. The managed object handles tasks associated with initializing and spawning the ResponseTime engine process, used by most ResponseTime modules.
This component requires the netiqmc agent process to run as Local System, which allows the agent to start the engine processes as different users. For more information, see Section 2.4, Permissions for Running Knowledge Scripts.
The specific ResponseTime engine process that handles the actual transaction. Module-specific engines are installed in %CommonProgramFiles%\Netiq\ResponseTime.
These engine processes run under the user account you specify for the Run As user parameters in the Knowledge Script.
Depending on the application transaction to be simulated by the Knowledge Script job, the ResponseTime engine may need to impersonate a user and/or log on to the application server. In some module-specific instances, this engine requires you to supply account and authentication information when you configure the job:
The values you supply for the Run As parameters in a Knowledge Script are used to impersonate a logged-in user and instantiate the application. If required, the ResponseTime engine process will be launched as this user.
The values you supply for the SQL Logon Knowledge Script parameters are used for authenticating the user on the application server, as, for example, with an Exchange Server or SQL Server user logon.
Sometimes these two options equate to the same information, especially in the case where the logon to the application server is handled by Windows Authentication, also called NTLM or “Integrated Security”.
The results you get from response-time testing with one of the SQL-RT Knowledge Scripts are extremely accurate because the network or server is “seeing,” and AppManager is timing, a transaction that looks just like a real transaction from the monitored server or client. Client-server emulation also lets you test your system the way end-users “test” it every day—and see the same results, and the same performance, that end-users are seeing.
When a response-time transaction runs, the agent measures the time taken to complete the transaction. This value is then returned as the ResponseTime data point. For most ResponseTime Knowledge Scripts, you can collect two types of data points:
Availability. The Availability data point is always created if the transaction is initialized and starts, meaning that the ResponseTime engine process is started. If the transaction completes without error, a data point of 1 or 100 is created, depending on the data stream format. Otherwise, the data point is 0.
If the ResponseTime engine process is not started due to initialization errors, no Availability data point is created, and a Transaction Initialization Error Event is raised.
Response Time. The Response Time data point is only created if the transaction completes successfully. The value of the data point is the total time required to run the transaction (in seconds).
In addition, you can collect up to six additional “Response Time Breakdown” data streams, individual data points for the different parts of the Knowledge Script transaction that are timed. These are explained in detail in the Help for each SQL-RT Knowledge Script.