2 Performance
2.3 Approach for the regulation of performance
The planning and execution of performance tests is an important, in addition, complex and complex process. In the last years many methods were not only developed for many ranges of computer science, in order to determine the performance from program products, components or complex systems to.
These fundamental steps are:
- Determination of the parameters, which express the achievement of the system.
- Definition of the demanded performance borders
- Execution of performance tests
- Comparison of actual and being
- Interpretation of the data for the determination of the weak point
- Optimization of the system and/or the software
B. Beizer subdivides the phases for the determination of the performance in the following way:
"Performance testing can be undertaken to: 1) show that the system meets specified performance objectives, 2) tune the system, 3) determine the factors in hardware or software that limit the system's performance, and 4) project the system's future load- handling capacity in order to schedule its replacements". [7]
Since this work is concerned with performance tests and the regulation of bottlenecks in multi-layer architectures, with the possibilities of the performance analysis by software one deals not more in greater detail, but one introduces only methods, which are designed by systems and their components also for the determination of the performance. Some these methods naturally also within other ranges are used.
2.3.1 Benchmarking
Both in computer science and within other ranges bench mark tests are far common. In computer science they serve the measurement of hardware components or - systems and make possible by comparison of the results to meet statements about their performance.
2.3.1.1 Mips und Flops
Into the 70iger years performance was represented by processors in Mips and flops. The abbreviation Mips stands for millions of instructions per second (“million Instructions by Second”), the abbreviation flop for floating point operations per second (“floating POINT operation by Second”). These units were far common and should give the possibility the performance from different processors to compare. But a real force of expression over the total performance is not attainable by these data, since the number of the operations or instructions does not only play a role, but also the kind of the instructions and their processing. Here only the different beginnings are RISC (“Reduced Instruction set computer”) and CISC (“Complex Instruction set computer”) mentions.
The measurements and the attained results are not sufficient, in order to really represent the performance of the overall system.
2.3.1.2 Whetstone-, Dhrystone-, Linpack- und Livermore-Benchmarks
Some the most well-known bench mark are Whetstone, Dhrystone, Linpack and Livermore bench mark, which were developed during the 70iger and 80iger years. After one recognized, which cannot only take place the determination of the performance from systems via “counting the implemented instructions”, but the necessity was seen to divide systems on the basis its performance bench mark was developed. It concerns test routines, which are implemented on the systems which can be tested and appropriate values to note.
That Whetstone bench mark was the first bench mark, which was written, in order to determine the performance from systems to. In addition it simulates floating point number operations. With the Dhrystone bench mark different operations are used for the determination of the CCU as well as the memory performance. In addition Integer and stringer operations belong. The unit Dhrystone indicates the number of runs per time unit, whereby a Dhrystone represents a program run per second. That Linpack bench mark derived from material applications and basedly on a collection from functions from linear algebra. It implements likewise floating point number operations, whose results are indicated in MFLOPS. [8][9]
2.3.1.3 SPEC - "Standard Performance Evaluation Corporation" [10]
SPEC was created 1988 by a small group of hardware offerers and makes available bench mark, it makes possible the performance from hardware components or systems to compare. SPEC develops portable test routines, which can work on the most different systems. The companies, which want to let their systems measure, know these test routines would drive out and their system in such a way to adapt that the test routines, which supply best results for the system. These results are collected by SPEC and put to everyone at the disposal. Since the test routines are not changed by SPEC thereby, the collected data of all companies are comparable in a high measure. SPEC leads its test routines on reference machines out around a firm point for comparison to likewise possess. For the test routines SPEC92 this was a VAX-11/780, for the SPEC95 a SPARCstation 10/40 (40MHz SuperSPARC without L2 cache).
In this way is to be made comparable for you succeeded the performance the parameters tested by system components and systems regarding. A problem consists of the fact that many companies align and optimize their systems particularly to the test routines, so that the total performance is to due not completely to the tested parameters.
2.3.2 Black-box-tests
With a black box test test datas are entered into a system. Without the knowledge about it, how these inputs of system are processed, one notes the results and environment variables, in order to meet statements about working the system.
In a multi-layer architecture, here a complex application of Web, is called this that the inputs are individual Web inquiries of users, whose execution and representation of the desired side need a certain time. This time is measured, without knowing, which steps were accomplished by mailing the inquiry, up to representing the side.
A problem with black box tests is the selection of the test cases. Since testing of all possible input combinations is usually not realizable, representative test cases must be selected. Here only “Equivalence Partitioning”, “limit value analysis” and “error Guessing” are mentioned. [11]
2.3.3 White-box-tests
Contrary to the black box tests, with which the knowledge is not considered over the structure of the system which can be tested, set White box test exactly with this concrete knowledge. Generally seen, White box tests try to cover as much as possible parts of a system or a program by test cases.
The goal of White box tests in the software development is it that code segments or also programs fulfill certain criteria. These can be differentiated according to supervisory data flow-dependent and data flow-dependent test criteria. The data flow-dependent criteria refer to variables and their permissible values, further distinctive according to instruction-covering, branch-covering the supervisory data flow-dependent criteria, multiple condition cover and path cover. Accordingly test cases are generated, which correspond to these requirements with and supply thus a good test scenario, in order to discover possible errors. However these test criteria are not sufficient, since the test cases do not reflect possibly the semantics of the system and not all control rivers were seized.
The problem, the collection of all control rivers, is already with larger programs a task hardly which can be mastered, since the number of paths for the path cover rises exponentially with the number of instructions. With multilevel architectures this problem remains existing and hardly makes it possible to produce a complete quantity of test cases in this kind. For this reason the traditional White box test is called also "code-based test". [12]
However the knowledge is helpful over the structure also with multilevel architectures and supports the production of special test cases, which load or even exclude for example individual components more strongly. This supports the error tracing substantially.
2.3.4 Grey-box-tests
The Grey box test is a method, which combines the advantages of the evenly specified black box and White box tests. Exact application is different. As can as with the black box test the test datas at the interface of the system entered, but for the analysis, which knowledge over the structure of the system which can be tested are used, in order to identify weak points. For applications of Web in a multi-layer architecture this is a not despising advantage.
Hung Quoc Nguyen describes the advantages of the Grey box test in its work "Testing Applications on the Web".
"It combines the insight of a software developer into the product (internal data structures, architecture on SOURCE code level), which in White box the Testing is used, with the aspect of the END user, who tests the expected behavior of application (black box Testing). For testing Web applications this approach of the Testing is substantially, there Web applications a multiplicity of components (both hard and software) contained of Gray box." [13]
Translated by Yahoo Babelfish Service
