<< Installation Overview
|
^ Index RTPL
|
Scripts >>
Measurement Strategy
In this section we will make some remarks about our measurement strategy and its
corresponding implications for the form and type of the
test scripts.
As explained in the "Description"
section. the measurements are started periodically. However, in a networked
environment connections may become slow or even get lost. This may result in a
much longer test time and in the worst scenario the test may even hung. We
believe that it is important to differentiate between lost and bad connections.
Therefore, we allow that the duration of the tests may last for some measurement
periods. A just started measurement exits when it is detected that a previous
test is still running.
To prevent that the tests will hung forever, the following measures are taken:
- For each performance measurement at a test host their exists a timeout
period. When it is passed the current measurement is skipped and a new one
is started. The current measurement is lost.
- Also a timeout at the control host for the measurements with the remote
shell at the control host is introduced. It may happen that:
- a large number of connection with the test host are bad.
- The remote shell connections from the control host to the test host is
bad. For some remote shells, including
ssh1
, this implies
that the shell hangs forever.
When this timeout period is exceeded the measurement at another test host
are started, but all data from the current test host are lost.
- When the connection between all test hosts or between the control host and
the test hosts are bad, the total number of timeouts may last too long to
wait for. Therefore, a newly started test at the control host will kill the
running one when it lasts too long.
However, in that case there always is a risk that a
data file which happens to be open is
damaged. To prevent the overwriting of a data
file by data from an older script when the killing might fail, a measurement
script does not write its data to file when it does run for a too long
period.
The following steps are taken too minimise the chance that a data file is
damaged by the killing of a running test:
- Data to save are stored in a new data file. To keep the data file open as
short as possible, the results of the tests are stored in memory as long as
the tests are running. After the tests the data buffer is written as one
large block.
- The current data file is moved to a backup file.
This also allows that still open file descriptors, used in for instance a
Web presentation, will keep on functioning correctly.
- Immediately after step 2. the new data file
is moved to its destination name. This make the time that the data file is
unavailable for the Web presentation as short as possible. However, when a
data file could not be read the user is informed that the data file probably
is unavailable for only a period. He/she is proposed to retry a reload.
- The next time a data file is opened by the measurement script to read the
old results also in memory, the backup file is used when the original file
was not available.
Of course these preventions are not completely failsafe. The data files where
the data of the current week and the data of the last 7 days are stored
have an acceptable chance of being damaged, because they are only open for a
limited period (current week data), or the damages are disappearing soon (data
of last 7 days). But in all mean data files the chances are cumulative
because new data are always added to the current values. Therefore, there are
dedicated scripts to recalculate the mean data files from the data files with
weekly data. It is recommended to run these scripts regularly. See the
"Scripts" section. See also the description
of the available data files in the
"Description" section.
To diminish the effects of corrupted data files, data in a bad format are
ignored by the measurement scripts and by the Web presentation of the results.
However, the existence some incorrect data can not be excluded completely. But
in the bulk of the correct data they are probably not very striking.
<< Installation Overview
|
^ Index RTPL
|
Scripts >>