The 2nd level cache, reduces traffic between your application and the database by conserving data already loaded from the database. Database access is therefore necessary only when the retrieving data is currently not available in the cache (refer to 2nd Level Cache and 2nd Level Cache Cluster for more information). These metrics tell you how effective the 2nd level cache and/or the 2nd level cache cluster is for your application/s. If the Cache Hit % is low then you may gain from increasing the maximum size of the cache. Be careful not to run out of memory (see General Metrics).
Level 2 Cache and Level 2 Cache Cluster Metrics
Category |
Metric |
Description |
OpenAccess ORM Cache |
L2 Object Cache Entries |
Number of objects currently cached. |
OpenAccess ORM Cache |
L2 Object Cache Hits |
Number of times data was found in the cache, i.e., number of successful object cache requests. |
OpenAccess ORM Cache |
L2 Object Cache Misses |
Number of times data was not found in the cache, i.e., number of unsuccessful object cache requests. |
OpenAccess ORM Cache |
L2 Query Cache Entries |
Number of queries currently cached. |
OpenAccess ORM Cache |
L2 Object Query Cache Hits |
Number of times query results were found in the cache, i.e., number of successful query cache requests. |
OpenAccess ORM Cache |
L2 Object Query Cache Misses |
Number of times query results were not found in the cache, i.e., number of unsuccessful query cache requests. |
OpenAccess ORM Cache Cluster |
Received eviction requests |
Number of received eviction messages. Any number of objects/queries can be evicted in a single message. |
OpenAccess ORM Cache Cluster |
Remote status requests |
Number of received status requests. |
OpenAccess ORM Cache Cluster |
Send eviction requests |
Number of sent eviction messages. |
There can be multiple instances of the counters; for every logical L2 cache and L2 cache cluster participant there will be one separate counter. Each instance name is constructed by appending the process id to the connection id to the L2 cache / cluster. Since there can be a slight performance impact when using the counters (as they have to be maintained), the counters are not enabled per default.
The <performanceCounter> property enables the counters. This setting can be specified within the <backendconfigurations> section of the application configuration file (refer to Backend Configurations for more information):
|
Copy Code |
<backendconfigurations>
<backendconfiguration id="mssqlConfiguration" backend="mssql">
<mappingname>mssqlMapping</mappingname>
<performanceCounter>true</performanceCounter>
</backendconfiguration>
</backendconfigurations>
|
 |
Creating and deleting performance counters is an administrative task and requires some rights. When there are insufficient rights, an appropriate exception is thrown. |