Answer:

Note: This FAQ does not discuss the impact of running the Foxhound database on the same computer as the target database. If both databases are heavily loaded it is probably a good idea to move Foxhound to a different computer.

Foxhound's overhead is approximately the same as a single persistent ODBC client-server connection that performs a small-to-medium (depending upon your point of view) amount of read-only query requests (three SELECTs) every ten seconds. The "Sample Times" column on the Monitor page shows how long it takes for Foxhound to do its work.

Generally speaking, if Foxhound's overhead causes any problems, the target database is already in serious difficulty for other reasons.

You can see the Foxhound connection in Foxhound itself; e.g., Foxhound-p001. It's not "zero impact" but it's not a heavy load either. The overhead goes up linearly with the number of other connections to the target database. For example, I have seen the CPU usage rise to 4% on a target database with 1000 idle connections; i.e., Foxhound was using 4% of the target server's CPU to gather information about 1000 connections every 10 seconds, even though those connections aren't doing anything.

Foxhound's overhead affects the CPU and client-server communications only; Foxhound performs no database disk I/O on the target database.

The Foxhound Monitor does almost all of its work inside its own SQL Anywhere server, so if you run that server on a different computer the impact on the target database server will be minimized. On the other hand, if you run Foxhound on the same box, and your target database is heavily loaded with a lot of connections, you can run into trouble.

Historically, Foxhound itself has had internal performance problems from time to time, but there has never been clear evidence of Foxhound adversely affecting a *target* database. "Clear evidence" would be a target database that performs well without Foxhound, and performs poorly with Foxhound.

One other factor has a large impact on Foxhound's own internal efficiency; here's a description:

In the status area of the Monitor page (just below the buttons), there is an SP OK: field over to the right. SPs OK: YYY, NNN or some combination of Ys and Ns indicates whether or not Foxhound has deployed, and is using, these three stored procedure on the target database: rroad_connection_properties, rroad_database_properties and rroad_engine_properties.

These stored procedures are used by Foxhound to improve the performance of the sampling process, but they are not absolutely required. If the user id that Foxhound uses to connect to the target database doesn't have the RESOURCE authority then Foxhound won't be able to CREATE these procedures on the target database.

The source code for the three procedures is in the Foxhound1 folder (C:\ProgramData\RisingRoad\Foxhound1 on Windows 7) so you can see what they do yourself:

rroad_connection_properties.sql
rroad_database_properties.sql
rroad_engine_properties.sql

The effect of these procedures is to reduce the number of rows of data, and the number of bytes, transferred from the target database to Foxhound every 10 seconds. That, in turn, has a significant effect on Foxhound itself if there a large number of connections. When those procedures are not available on the target database, Foxhound calls these three system procedures on the target database every ten seconds: sa_conn_properties(), sa_db_properties() and sa_eng_properties().

For more information about these procedures see Connecting to Target Databases.