Formulating a performance expectation

The following fundamental relation holds between the transaction time, the transaction rate and the number of terminals:

(Think time + Transaction time) * Transaction time = Number of terminals

The term “transaction time” summarizes the system's reaction to a wide variety of requirements. For this reason it is difficult to decide whether a transaction time is appropriate or not. Due to the costs involved in operating the terminal and the user's working hours, the following method is recommended:

The terminal cannot be used during the transaction time as it is waiting for the server. During the think time the terminal and user interwork by reading the output or typing in a new entry. The proportion of think times in the total busy time of the terminal is the efficiency value E for terminals. If the average value for all terminals drops below 75%, this is an indication of performance problems. Of course, pauses for a “breather” must not be taken into account when calculating think times.

The following values are used:

TH: Think Time
TT: Transaction Time
TR: Transaction Rate

According to the definition, the following is true for the efficiency value (E) for terminals:

E = TH / (TH + TT)

Let the number of transactions to be performed per second for an application be TR. Assuming the number of terminals required for this application is K, then

K = (TH + TT) * TR

K = TH / E * TR

If an efficiency value of 0.75 is assumed for terminals, the formula is:

K = 1,33 * TH * TR

The table below contains the values for 1/E for various efficiency values.

E [%]	70	75	80	85	90	95
1/E	1.43	1.33	1.25	1.18	1.11	1.05

The formula E = TH / (TH + TT) shows that relatively long transaction times (or response times in the case of only one response per transaction) can be accepted in the event of long think times, while in the event of short think times the transaction times have a lasting effect on the efficiency value and hence on the number of terminals required.

The number of terminals required is determined by the utilization (U) of the terminal as well as by the efficiency value. The utilization is the proportion of the total time spent by the machine either waiting for a response (transaction time) or preparing a new input (think time). Time taken for a “breather”, for instance, reduces the utilization without the device really being free. In the case of a data entry application, documents are generally processed from a stack. Workstations can therefore be utilized to a very high level.
It is possible to achieve terminal utilization of 90% under these conditions. A slight loss of 10% is allowed for to accommodate “breathers”. Utilization must be set lower for other applications. In the case of TP mode with customer traffic, it is desirable to eliminate inconvenient waiting times for the customers. These occur when there is no terminal free and hence the customer cannot be served immediately. The situation is similar in the case of program development. In cases such as this, terminal utilization (U) should not exceed 60%.

The number of terminals (K) required can then be calculated by:

K = (TH * TR) / (E * U)

Example

The following two applications exist:

The first application is a data entry application with a think time of 20 seconds and a transaction time of 1 second. On average 90% of all data entry stations are always in use. 7,200 documents must be processed per hour.

The second application is a seat booking application and involves dealing with the public. Think time is 120 seconds and transaction time is 3 seconds. In order to avoid noticeable delays for customers who wish to book, terminals are only utilized to 60% of their capacity. 360 bookings per hour must be processed.

E₁ = 95%; U₁ = 90%; TR₁ = 2/s

(E₁ = TH / (TH + TT) = 20s / (20s + 1s) = 0.95)

E₂ = 97%; U₂ = 60%; TR₂ = 0.1/s

K₁ = (20 * 2) / (0.95 * 0.90) = 47 terminals

K₂ = (120 * 0.1) / (0.97 * 0.60) = 21 terminals

A total of 68 terminals are required for both applications. You must ensure that the values for the transaction time contained in the efficiency value for terminals are feasible for the server.
This constitutes the performance expectation which needs to be calculated.

It can only be met if the resources required by the application do not exceed the limits of the server and the server has a certain amount of reserve capacity. Here the load on those resources which are heavily used by the application concerned plays a particularly important part. If the application involves a large number of I/O operations to disk, you must ensure that utilization of the disk drives is kept at a low level. The situation is not improved by additional spare capacity in the server.
The opposite is true of applications which require a large number of calculations. Paging is unhelpful in both cases.

There is a natural lower limit for all transaction times. This is reached when a terminal performs its transaction using a server which is otherwise completely free of other operations and using data transmission paths which are equally free of other operations. It is, of course, not cost-effective to use an IT system like this. If other terminals and, where appropriate, other applications are added, the time required for execution is extended due to mutual obstruction by the transactions.

A dilation factor (D) is defined:

D = TT (current workload) / TT (empty server)

This dilation factor is the price is to be paid for the economic utilization of the system. To what extent a particular dilation factor is acceptable depends in turn on the think time and the optimal transaction time TT (unoccupied server). Dilation factors of 10 are still acceptable in the case of short transaction times and long think times. If, in the case of a think time of only 10 seconds, the optimal transaction time is even as much as 3 seconds, then a dilation factor of three is already too large. The optimal transaction time can either be measured on a server otherwise free of other operations or be estimated using the following formula:

TT (empty server) = CPU + n * IO + NL

where:

CPU: CPU time required for the transaction
IO: mean time for an I/O operation
n: number of I/Os (including paging) required for the transaction
NL: network runtime for the input and output messages

All these values can be altered by means of modification to the hardware or the software. In the case of the CPU and I/O times, several tasks generally have to be taken into account, in transaction mode, for example, UTM and DBH tasks.

The dilation factor measured by SM2 does not take the network runtime into account. Only the internal server data is processed.

Example 1

Database query with the following values:

CPU=0.1s
IO=0.004s
NL=0.1s
n=60

TT (empty server) = 0.1s + 60 * 0.004s + 0.1s = 0.44s

Using a dilation factor of 3 for the server and the network results in a TT_current of 3 * 0.44 = 1.32 (= ca. 1.3). Using a think time of 40 seconds, the efficiency value for terminals can be calculated at 97%:

E = TH / (TH + TT_current) = 40s / (40s + 1.3s) = 0.97

If the think time is only 20 seconds, the efficiency value for terminals drops to 94%.
In this case you should check whether the I/O times could be reduced, for instance by reducing the number of inputs/outputs or quicker peripherals.

Example 2

Scrolling in the editor with the following values:

CPU=0.01s
IO=0.004s
NL=1s
n=2

TT (empty server) = 0.1s + 2 * 0.004s + 1s = 1.02s

The important factor here is the transmission time for the output screen. Even if the disks on the server are overloaded (e.g. 0.025 s per I/O operation), the transaction time is only marginally increased to 1.06 s. A think time of 3 seconds results in an efficiency value for terminals of 75%. This is unsatisfactory.

E = TH / (TH + TT) = 3s / (3s + 1.02s) = 0.746

A doubling of the line speed in this case results in an optimal transaction time of
0.53 seconds. If it is assumed that no dilations occur during the transmission of messages, then this transaction time remains valid even when the server has a realistic workload. In this case the efficiency value for terminals rises to 85%.

These two examples show how varied the causes for inadequate performance can be. Overloading can occur in the CPU or in the peripherals, as can combinations of bottlenecks. For help in locating and solving problems like this, see section “Basic procedure”.

The formulas and examples above demonstrate the way in which users should formulate their performance expectations for online operation. Their intention is always to minimize costs. If savings (e.g. in staff and terminals) on the one hand are set off against increased costs (e.g for faster lines, faster processors, faster disks or program alterations) on the other, then one always arrives at a sound performance expectation. Any decisions reached should always be examined at regular intervals in the light of fluctuations in the price of hardware.

Of course, subjective considerations such as the psychologically damaging effect of occasional long transaction times must not be ignored completely. However, performance expectations based upon these considerations are misleading. Eliminating individual long transaction times is generally a very complicated operation and does not normally lead to overall savings.