Cache Performance Test

This test monitors the critical determinants of the performance of a Cache database server. This includes:

  • Code processing speed
  • Routine loads and saves
  • Global jobs
  • Logical block accesses
  • Journal entries
  • Locking activity

Target of the test : A Cache Database server

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every InstanceName configured

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed.
  2. Host – The IP address of the Cache Database Server.
  3. Port – The port on which the server is listening.
  4. SnmpPortThe port at which the Cache Database Server exposes its SNMP MIB; the default is 161.
  5. SNMPVERSION– By default, the eG agent supports SNMP version 1. Accordingly, the default selection in the snmpversionlist is v1. However, if a different SNMP framework is in use in your environment, say SNMP v2 or v3, then select the corresponding option from this list.
  6. SNMPCommunity – The SNMP community name that the test uses to communicate with the firewall. This parameter is specific to SNMP v1 and v2 only. Therefore, if the snmpversionchosen is v3, then this parameter will not appear.
  7. username– This parameter appears only when v3 is selected as the snmpversion. SNMP version 3 (SNMPv3) is an extensible SNMP Framework which supplements the SNMPv2 Framework, by additionally supporting message security, access control, and remote SNMP configuration capabilities. To extract performance statistics from the MIB using the highly secure SNMP v3 protocol, the eG agent has to be configured with the required access privileges – in other words, the eG agent should connect to the MIB using the credentials of a user with access permissions to be MIB. Therefore, specify the name of such a user against the username parameter. 
  8. CONTEXT – This parameter appears only when v3 is selected as the SNMPVERSION. An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts. A context is identified by the SNMPEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName). If the USERNAME provided is associated with a context name, then the eG agent will be able to poll the MIB and collect metrics only if it is configured with the context name as well. In such cases therefore, specify the context name of the USERNAME in the CONTEXT text box.  By default, this parameter is set to none.

  9. authpass– Specify the password that corresponds to the above-mentioned username. This parameter once again appears only if the snmpversion selected is v3.
  10. confirm password– Confirm the authpass by retyping it here.
  11. authtype– This parameter too appears only if v3 is selected as the snmpversion. From the authtypelist box, choose the authentication algorithm using which SNMP v3 converts the specified username and password into a 32-bit format to ensure security of SNMP transactions. You can choose between the following options:

    • md5 – Message Digest Algorithm
    • sha – Secure Hash Algorithm
  12. encryptflag– This flag appears only when v3 is selected as the snmpversion. By default, the eG agent does not encrypt SNMP requests. Accordingly, the encryptflagis set to no by default. To ensure that SNMP requests sent by the eG agent are encrypted, select the yes option. 
  13. encrypttype– If the encryptflagis set to yes, then you will have to mention the encryption type by selecting an option from the encrypttypelist. SNMP v3 supports the following encryption types:

    • des – Data Encryption Standard
    • AES – Advanced Encryption Standard
  14. encryptpassword– Specify the encryption password here.
  15. confirm password– Confirm the encryption password by retyping it here.
  16. TIMEOUT - Specify the duration (in seconds) within which the SNMP query executed by this test should time out in the TIMEOUT text box. The default is 10 seconds.
  17. DATA OVER TCP – By default, in an IT environment, all data transmission occurs over UDP. Some environments however, may be specifically configured to offload a fraction of the data traffic – for instance, certain types of data traffic or traffic pertaining to specific components – to other protocols like TCP, so as to prevent UDP overloads. In such environments, you can instruct the eG agent to conduct the SNMP data traffic related to the monitored target over TCP (and not UDP). For this, set the data over tcp flag to Yes. By default, this flag is set to No.
  18. instancename – By default, this is set to All, indicating that all Cache instances will be monitored. To monitor specific instances, provide a comma-separated list of Cache names.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Lines executed:

Indicates the number of lines of code per second that were executed on the server.

Lines/Sec

This serves as a good measure of the processing capability of the database server.

Routine loads/saves:

Indicates the rate at which routine loads and saves occurred.

Routines/Sec

Routines are small programs that run within a Cache database server. In a well-tuned environment, this number increases slowly, since most routine loads are satisfied by the routine cache memory without accessing the disk. Each routine load or save transfers up to 32 KB of data.

New global references:

Indicates the rate of at which new global references were set in this database instance. 

 

Refs/Sec

A global is a named multidimensional array that is used for storing data in a physical Cache database. Data can be spread across many globals that exist in different databases on the same system or remote systems. Using a namespace, you can group closely related globals and databases, so that data can be easily referenced.

Cross-referencing of data ensures better data storage and efficient query execution.

New global sets:

Indicates the rate at which new globals were created in this database instance.

Sets/Sec

This measure considers the rate of Set operations performed on this database instance since the last measurement period. 

New global kills:

Indicates the rate at which new globals were killed in this database instance.

Kills/Sec

This measure considers the number of kill operations per second performed on this database instance since the last measurement period. 

Logical database block reads:

Indicates the rate at which data blocks were read from the disk.

 

Blocks/Sec

Globals are stored on disk within a series of data blocks; the size of each block (typically 8KB) is determined when the physical database is created.

A high value for this measure indicates that direct disk accesses are high. In such a case your database might require some fine-tuning. Consider resizing your buffer pool to increase buffer accesses and reduce data retrievals from the disk.

Physical database block reads:

Indicates the rate at which physical database blocks (2-KB or 8-KB) were read from disk for both global and routine references.

Blocks/Sec

A high value for this measure indicates that direct disk accesses are high. In such a case your database might require some fine-tuning. Consider resizing your buffer pool to increase buffer accesses and reduce data retrievals from the disk.

Physical database block writes:

Indicates the rate at which physical database blocks (2-KB or 8-KB) were written to disk for both global and routine references.

Blocks/Sec

 

New database journal entries:

Indicates the number of entries recorded in the journal during this measurement period.

Number

To provide database integrity and reliability, Cache includes a number of journaling subsystems that keep track of physical and logical database updates. The journal management technology is also used to provide transaction support (a journal is used to perform transaction rollback operations) as well as database shadowing (a journal is used to synchronize a shadow server with a primary data server).

This measure hence aids in effective audit tracking of your database, as it can tell you whether any modifications have been performed on the database - be it a set/kill/transaction event. Since the events for which journaling is needed is configurable, you might want to track critical changes to your database by enabling journaling.

Lock commands:

Indicates the number of lock commands that are issued in the last measurement period.

Number

 

Lock successes:

Indicates the number of lock commands that succeeded in the last measurement period.

Number

When the attempt to lock a transaction succeeds, it means that other processes will be prevented from seeing the modifications to the transaction, until the transaction is committed.

Lock failures:

Indicates the number of lock commands that have failed in the last measurement period.

Number

A lock command typically fails when it is unable to acquire a lock on a transaction - this happens when the transaction to be locked is already locked by another process.

Current global jobs:

Indicates the number of jobs currently counted ‘in global’.

Number

 

Max global jobs:

Indicates the maximum number of jobs currently counted ‘in global’.

Number

 

Throttle wait jobs:

Indicates the number of jobs required to wait for a throttle.

Number

 

Write update status:

 

Indicates whether /not the Write Daemon has successfully updated the database.

Boolean

Rather than writing directly from memory to the database, the Cache write daemon system process (WRTDMN) uses an intermediate file, the write image journal. This file is usually named cache.wij.

Write image journaling technology uses a two-phase process of writing to the database, as follows:

  • In the first phase, Cache records the changes needed to complete the update in the write image journal. Once all updates to the write image journal have been entered, a flag is set in the file and the second phase begins.
  • In the second phase, the Write daemon writes the changes recorded in the write image journal to the database on disk. When this second phase completes, the Write daemon sets a flag in the write image journal to indicate it is empty.
  • When Cache starts, it automatically checks the write image journal and runs a recovery procedure if it detects that an abnormal shutdown occurred. When Cache indicates successful completion, the internal integrity of the database is restored.

    Recovery is necessary if a system crash or other major system malfunction occurs at either of the following points in the two-phase write protocol process:

  • Before the Write daemon has completed writing the update to the write image journal. In this case, recovery discards the incomplete entry.
  • After the update to the write image journal is complete but before the update(s) to the database is complete. In this case, recovery rewrites the updates from the write image journal file to the database.

Note:

The two-phase write protocol safeguards structural database integrity, but it does not prevent data loss. If the system failure occurs prior to a complete write of an update to the write image journal, Cache does not have all the information it needs to perform a complete update to disk. That data is lost.

If the value of this measure is ‘1’, it indicates that the daemon has written to the database successfully. The value ‘0’, on the other hand, indicates an unsuccessful attempt to perform global updates.

 

 

Users updating:

Indicates the number of users performing global updates.

Number

 

Write daemon status:

Indicates the status of the write daemon.

Boolean

The value 1 indicates that the write demon is  running, and the value 0 indicates that write demon is  waiting for wakeup. If this value becomes 2, it indicates that Cache stopped the write daemon to prevent further harm.