Chapter 2

In this section we explain important terms used throughout the thesis.

2.1 Caching

Caching (noun: cache, from the French word cacher – to hide) is the temporary storage of data for later retrieval. Necessary for this approach is a certain persistance of the data to be stored. The motivation for caches is the gain of speed whilst trying not to deliver outdated content. The gain of speed manifests in three points (compare with [Wes01]):

Quick retrieval requires fast memory. That is the reason in hardware often small and expensive memory – but fast one – is used.

Generally speaking, a cache should never be visible to the user, it should be a transparent means for speeding up the delivery of data.

2.1.1 Invalidation

A cache needs to provide means for invalidating its contents or parts of it in order to avoid the delivery of outdated data. There are two main concepts for invalidation:

Both strategies have their advantages. Chosing the right one depends on the circumstances. Command based invalidation proxies need very little logic, but are also very susceptible for delivering invalid data, for example, if an invalidation command gets lost for some reason.

The second approach needs more intelligence for the proxy, but allows minimization of delivering old data. As it is difficult to define a lifetime for a certain cached object, though, it is quite easy to implement a last-modification check which compares the version available in the cache to the “real” one. This can be done every few times the resource is requested or – if the check is inexpensive – upon each retrieval.

2.1.2 Privacy

A dangerous field for caching is the privacy of data. Often the contents to be stored can include sensitive data which has to remain uncached. Although this issue should be avoided by using encryption, it is – especially in the WWW – quite common to transmit user specific data through an insecure, plain text channel.

Caches should therefore either be aware of a kind of “private flag” or support the tagging of content – storing extra information for data, marking it as a belonging to a certain user. Often this can be implemented in combination with an authenticated (e.g. by user passwords) proxying system.

2.2 Load

The topic of this diploma thesis includes the technical term “load”. Although most IT professionals know what load is they would not be able to define it clearly.

A common answer when asking for a definition of “load” is “the degree of occupation of the CPU”. In the Windows operating system the system load is indeed displayed (e.g. in the “Task Manager”) using a percentage between 0% and 100%.

2.2.1 Using the uptime command

In Unix the load is usually recognized by three values that can be displayed e.g. by using the uptime command.

Listing 2.1: Output of the uptime command
alex@notebook:~$ uptime 
 12:32:52 up  2:23,  3 users,  load average: 1.16, 1.13, 1.09

According to the man page (1) of uptime these are “the system load averages for the past 1, 5, and 15 minutes.” So these values do not actually represent the load of the system but average values, so this is a mean value for three periods of time.

2.2.2 Using the top command

The current load of the system can be shown by using the top command (see listing 2.2). It also includes the load averages but additionally a percentage for CPU load is being displayed.

Listing 2.2: A part of the output of the top command
alex@notebook:~$ top 
top - 12:32:52 up  2:23,  3 users,  load average: 1.16, 1.13, 1.09 
Tasks:  84 total,  1 running,  83 sleeping, 0 stopped, 0 zombie 
Cpu(s):  5.0% us,  0.3% sy,  0.0% ni, 94.7% id,  0.0% wa, 
             0.0% hi,  0.0% si

The current occupation of the CPU is split into 7 parts to give a more precise overview. The abbreviations mean the following:

2.2.3 Load Averages

Although the top command gives a quite intuitive overview over the current system load, load averages are highly important for diagnosing the “working” load for a system. The current state is not very informative when the system does not respond due to a highly CPU intense process – (even afterwards) the load average can still be helpful.

Interestingly there does not seem to be a single, valid definition on how the load average is calculated and how it shall be interpreted. According to [Gun03] the load averages are constructed using the CPU run queue and the number of jobs currently running on the CPU. The article describes the calculation in more detail and even provides a second part going even further into detail.