Shared Cache

Shared Cache Topology

Shared Cache Client

Shared Cache Server

Shared Cache Notify

Shared Cache Config

Shared Cache Stats

Getting Started

Console Test App

Tips and Tricks

Service Cleanup

LRU

LFU

LLF

Cache Item Priority

Timebased

Size

Hybrid

Configuration Server

Configuration Client

Configuration Notify

Configuration NLog

Distributed Caching

Replicated Caching

Client Distributed Caching

Client Replicated Caching

REP_NLB

Discussion

Bugs

Contact Us

Special Thanks

Disclaimer

Contribute Shared Cache

DotNet Caching

Browser Caching

Caching Asp.Net Pages

Caching portions of Asp.Net Page

Caching application data

Setting output cache location

General information about output caching

Links

Why use shared cache?

There is no more efficient way to increase the scalable performance of applications then the use caching to unload deeper layers.

>> Shared Cache>> Shared Cache Stats

Shared Cache Statistical Information

This section of statistical information is divided into 2 sections:

• Client data
• Server data

Client and Server Information is gathered together into one view. Upon every call every information is recalculated therefore we do not suggest to use this to often upon run-time. The picture below shows the output of all available information which can received over the stat call.

Client Data

The first bunch of information shows different communications which happened between the specific client and the server.

1. # objects have been added - the total amount of items which are added during the life time of the client.
2. # objects have been received - the total amount of items which are received during the life time of the client.
3. # objects have been removed - the total amount of items which are removed during the life time of the client.
4. # statistics have been called - the total amount of items which are removed during the life time of the client.

The second client relevant part is about network information. This makes the information available how much data have been sent and received between the specific client and the server.  There is always a chance that an action will fail because of several reasons. Therefore we decided also to count the amount of items which are added / removed / received successfully or failed.

1. # MB have been transferred to server - the total amount during the life time of the client.
2. # MB have been received from server nodes - the total amount during the life time of the client.
3. # transfer succeeded - the total amount during the life time of the client.
4. # transfer failed - the total amount during the life time of the client.
5. # % relation between successfully and failed actions - the total amount during the life time of the client.

The third relevant client section is to figure out hit ration. This gives an identification how good the cache is working. The target should be always more then 95% but this really depends on the application its used and the amount of data. Last but not least, its also a question of available hardware.

1. # received objects - the total amount during the life time of the client.
2. # not available objects  - the total amount during the life time of the client.
3. # % ratio - relation between successfully and failed results  - the total amount during the life time of the client.

Server Data

The Server Data part is always depend on amount of server nodes. Every call of to gather statistical information makes an aggregation of all available server nodes.

1. # items included in all available cache nodes
2. # kb - all the items as an aggregated value.
3. A list with the 20 most used keys in all cache nodes.

 

• Free Quizzes