From 48ef4e6ac6a6a2ec83671c7057cdb2351d81eba0 Mon Sep 17 00:00:00 2001 From: markk <> Date: Mon, 28 May 2001 15:05:49 +0000 Subject: [PATCH] measuring performance --- .../docbook/Tuning-Linux/measurement.sgml | 170 ++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 LDP/guide/docbook/Tuning-Linux/measurement.sgml diff --git a/LDP/guide/docbook/Tuning-Linux/measurement.sgml b/LDP/guide/docbook/Tuning-Linux/measurement.sgml new file mode 100644 index 00000000..4a5436ea --- /dev/null +++ b/LDP/guide/docbook/Tuning-Linux/measurement.sgml @@ -0,0 +1,170 @@ + + Measuring your performance + + In order to see if your system is any faster, you need to measure + the performance of the system before and after you try your tuning + changes. There's a variety of applications for testing your hard drive, + CPU, memory, and overall system performance. This allows you to also test a + proposed configuration versus the existing configuration. + + + In all cases of testing, you should have a relatively quiet system, meaning + that there is a minimum of applications running. For true testing, you + should reboot the machine between each test, and run each test at least + 5 times, then take the average. Rebooting clears any in-memory caches that + can affect the tuning numbers, and also makes sure there is a larger amount + of system RAM free. + +
+ Hard Drive + + The easiest way to find raw hard drive performance is using + hdparm, which we describe in . But this is raw hard drive performance, not + taking into account things like overhead from the filesystem or write + performance. + + + The other application you can use to test how the filesystem works, or for + devices that do not work with hdparm is to use + dd. The dd command is used to write + or read data and perform some conversion along the way. The nice part of + the command for us is that it can create a file of any size containing + ASCII NULL (0), which allows us to test consistently. + Since the data we want to write is being generated in the CPU and memory + which is always faster than the hard drive, this gives a good look at the + disk bottleneck. + + + This is used in conjunction with time which gives + the amount of CPU, system, and user (real) time used to run a particular + command. You can then divide out the size of the file created by the + number of user seconds to run the command to get a Mbps rating. + + +
+ +
+ CPU and System + + Since CPUs have a variety of functions crammed into a small space, it is + hard to test how fast a particular CPU is. A standard number for Linux is + called BogoMIPS, which Linus needed for some timing + routines in the kernel. BogoMIPS calculate how fast a CPU can do nothing, + and so will vary depending on the kind of chip used. Because of how + BogoMIPS are calculated, they should not be used for any form of + performance measurement. + + + There are a variety of CPU functions that can be measured, including + Million Instructions Per Second (MIPS), Floating Point Operations Per + Second (FLOPS), and memory to CPU speed (in MBps). Each of these will + vary greatly depending on the choice of CPU. MIPS are almost worthless, + since some chips can have one instruction that runs multiple other + instructions. The MMX instruction set for Intel-based hardware is a good + example for this, as MMX is set to perform matrix operations from just a + few instructions, whereas without MMX, it would take many more operations + to do the same calulations. When measuring chip speed, does an MMX + instruction count as one or multiple instructions? Since the speed of + running one MMX instruction is slightly faster than running the multiple + instructions that make it up, it will make an MMX-based chip appear + slower. + + + Many online reviewers use games as a measurement of the CPU. The idea is + that 3D games provide a good stress test of the CPU, memory interface, + system bus, and video card. The result is the number of Frames Per Second + (FPS). More FPS means a faster overall system. Since most servers do not + have a 3D card in them, this may not be a good choice of measurement. + Workstations may get a benefit from this kind of testing, however. + + + One other measurement form is that of other third-party applications. + Applications like SETI@Home, distributed.net can give generic speed + ratings that are good to compare against other machines running the same + software. Other CPU-intensive applications like MP3 encoders can also be + a good guide of how fast a CPU is. The down side to these are that the + results have to be compared to the results of other machines running the + exact same software. If the software is not available for that + OS/Hardware combination, the test is worthless. + + + So what does this leave us with? Unfortunately, not a lot. The best bet + appears to be MIPS and FLOPS, since it does test instructions per second, + and as + long as the chipset remains the same (Intel based, SPARC, Alpha, etc.), + the + measurements can be compared pretty easily and the comparisons will be + close enough. + +
+ +
+ Network + + Measuring the network speed is not quite easy, since there are bottlenecks + outside the network interface and your machine. Cable problems, poor + choice of switching gear, and congestion on the line or the remote machine + you want to test against can all reduce the throughput of your network + interface. In addition, protocols like SSH or HTTP have additional + processing that may need to be done that occupies the CPU and reduces + throughput. + + + If the machine you are testing is going to be a server, you can create a + small group of client machines on a private network. These machines + should have the same type of network card and OS revision. This will + create a stable baseline of testing. + + + Depending on the networking application you will be using, there may be + applications that already exist to automate this testing for you. + Programs like webbench can coordinate the + clients talking to the server, and be able to read the performance of the + server in terms of pages per second. + + + +
+ +
+ Video card + + If you want to tune a workstation, or create a killer Quake III box, you + will want to pay attention to the video subsystem and see how well it + performs. For 2D applications, you can test the system using + x11perf. This program will perform a variety of tests + using the X server and drivers. Since it is designed for performance + testing, it is designed to run each test five times, then take the + average. The machine should have no other users or activity going on, and + you should disable the screen saver. You can disable the screensaver + either with the command xset s off or by killing the + process called xscreensaver. You may need to run both + commands in order to turn off the screen saver. + + + Testing with x11perf will take several hours depending + on the speed of your CPU and graphics card. Once complete, you will have + a log file that you can then compare against other machines that have also + done testing, or against a baseline test you ran before tuning to see if + the X server speed has been improved. To do this comparison, you can use + x11perfcomp to compare two or more tests. Higher + numbers are better, as the resulting numbers are in terms of objects per + second. + + + You can test out 3D performance using applications like Quake III, that + run the application through a set world and events, most of which will + stress the system. Mark down the resolution, bit depth, and frames per + second reported from Quake III, and you now have a baseline to work from. + + + A caveat to using Quake or 3D applications is that this is testing more + than the video card. Other subsystems, like the CPU, video drivers, GLX + (3D) drivers, and memory are also tested. If you want to use this method + for comparing speed, you should also be sure the other subsystems are + tuned as well. + +
+ +