<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
$FreeBSDde: de-docproj/books/developers-handbook/testing/chapter.sgml,v 1.10 2010/12/18 13:28:29 jkois Exp $
basiert auf: 1.3
-->
<chapter id="testing">
<chapterinfo>
<authorgroup>
<author>
<firstname>Jürgen</firstname>
<surname>Lock</surname>
<contrib>Übersetzt von </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Regressions- und Performance-Tests</title>
<para>Regressions-Tests werden durchgeführt, um zu überprüfen,
ob ein bestimmter Teil des Systems wie erwartet funktioniert, und
um sicherzustellen, dass bereits beseitigte Fehler nicht wieder eingebaut
werden.</para>
<para>Die &os;-Regressions-Testwerkzeuge finden Sie im
&os;-Quelltextbaum unter <filename
class="directory">src/tools/regression</filename>.</para>
<section id="testing-micro-benchmark">
<title>Mikro-Benchmark-Checkliste</title>
<para>Dieser Abschnitt enthält Tipps, wie
ordnungsgemäße Mikro-Benchmarks unter &os; oder für
&os; selbst erstellt werden.</para>
<para>Es ist nicht möglich, immer alle der folgenden
Vorschläge zu berücksichtigen, aber je mehr davon,
desto besser wird der Benchmark kleine
Unterschiede nachweisen können.</para>
<itemizedlist>
<listitem>
<para>Schalten Sie <acronym>APM</acronym> und alles andere,
das den Systemtakt beeinflusst, ab
(<acronym>ACPI</acronym>?).</para>
</listitem>
<listitem>
<para>Starten Sie in den Single-User-Modus. &man.cron.8;
und andere Systemdienste verursachen nur Störungen.
Genauso der &man.sshd.8;-Systemdienst.
Falls während des Tests
SSH-Zugriff benötigt wird, schalten Sie entweder die
Neuerstellung des SSHv1-Schlüssels ab oder beenden Sie
den <command>sshd</command>-Elternprozess während der
Tests.</para>
</listitem>
<listitem>
<para>Beenden Sie &man.ntpd.8;.</para>
</listitem>
<listitem>
<para>Falls &man.syslog.3;-Ereignisse erzeugt werden,
starten Sie &man.syslogd.8; mit leerer
<filename>/etc/syslogd.conf</filename> oder beenden Sie
es.</para>
</listitem>
<listitem>
<para>Sorgen Sie für möglichst wenig Disk-I/O;
vermeiden Sie es ganz wenn möglich.</para>
</listitem>
<listitem>
<para>Hängen Sie keine Dateisysteme ein, die Sie nicht
benötigen.</para>
</listitem>
<listitem>
<para>Hängen Sie <filename
class="directory">/</filename>, <filename
class="directory">/usr</filename> und die anderen
Dateisysteme nur lesbar ein wenn möglich. Dies
verhindert, dass atime-Aktualisierungen auf der Festplatte (usw.) das
Ergebnis verfälschen.</para>
</listitem>
<listitem>
<para>Initialisieren Sie das beschreibbare
Test-Dateisystem mit &man.newfs.8; neu und füllen Sie es
aus einer &man.tar.1;- oder &man.dump.8;-Datei vor jedem
Lauf. Hängen Sie es aus und wieder ein, bevor Sie den
Test starten. Dies sorgt für einen konsistenten
Dateisystemaufbau. Bei einem <quote>worldstone</quote>-Test
bezieht sich dies auf <filename
class="directory">/usr/obj</filename> (Initialisieren Sie
es einfach mit <command>newfs</command> neu und hängen Sie
es ein). Um absolut reproduzierbare Ergebnisse zu bekommen,
füllen Sie das Dateisystem aus einer &man.dd.1;-Datei
(d.h. <command>dd
if=<filename>myimage</filename> of=<filename
class="devicefile">/dev/ad0s1h</filename>
bs=1m</command>).</para>
</listitem>
<listitem>
<para>Benutzen Sie malloc-gestützte oder vorbelastete
&man.md.4;-Partitionen.</para>
</listitem>
<listitem>
<para>Starten Sie zwischen den einzelnen
Durchläufen neu, dies sichert einen konsistenteren
Zustand.</para>
</listitem>
<listitem>
<para>Entfernen Sie alle nicht unbedingt benötigten
Gerätetreiber aus dem Kernel. Wenn z.B. USB für
den Test nicht benötigt wird, entfernen Sie es aus dem
Kernel. Gerätetreiber, die sich Hardware zuteilen, haben
oft <quote>tickende</quote> Timeouts.</para>
</listitem>
<listitem>
<para>Konfigurieren Sie nicht Hardware, die
nicht benutzt wird. Entfernen Sie Festplatten
mit &man.atacontrol.8; und &man.camcontrol.8;, wenn diese
für den Test nicht gebraucht werden.</para>
</listitem>
<listitem>
<para>Konfigurieren Sie nicht das Netzwerk, es sei denn es
wird getestet, oder warten Sie, bis der Test fertig ist, wenn
Sie das Ergebnis auf einen anderen Rechner übertragen
wollen.</para>
<para>Falls das System an ein öffentliches Netzwerk
angeschlossen sein muss, achten Sie auf Spitzen im
Broadcast-Verkehr. Obwohl dieser kaum auffällt, wird
er CPU-Zyklen brauchen. Ähnliches gilt für
Multicast.</para>
</listitem>
<listitem>
<para>Legen Sie jedes Dateisystem auf eine eigene Festplatte.
Dies minimiert Jitter durch Optimierungen von
Lesekopfbewegungen.</para>
</listitem>
<listitem>
<para>Minimieren Sie Ausgaben auf serielle oder VGA-Konsolen.
Ausgabenumleitung in Dateien ergibt weniger Jitter
(serielle Konsolen werden leicht zum Flaschenhals).
Benutzen Sie die Tastatur nicht, während der Test
läuft, sogar <keycap>space</keycap> oder
<keycap>back-space</keycap> wirken sich auf die
Ergebnisse aus.</para>
</listitem>
<listitem>
<para>Stellen Sie sicher, dass der Test lang genug
läuft, aber nicht zu lange. Wenn er zu kurz ist, sind
Zeitstempel ein Problem. Wenn er zu lang ist, werden
Temperaturänderungen und Drift die Frequenz von
Quarzkristallen im Rechner beeinflussen. Daumenregel: mehr
als eine Minute, weniger als eine Stunde.</para>
</listitem>
<listitem>
<para>Versuchen Sie, die Temperatur in der Umgebung des
Rechners so stabil wie möglich zu halten. Diese beeinflusst
sowohl Quarzkristalle als auch Festplatten-Algorithmen.
Um einen wirklich stabilen Takt zu erhalten, wäre es auch
möglich, einen stabilisierten Takt anzuschließen.
D.h. besorgen Sie sich einen OCXO + PLL und koppeln Sie das
Ausgangssignal mit den Taktgeberschaltkreisen anstelle des
Quarzkristalls der Hauptplatine. Wenden Sie sich an
&a.phk;, wenn Sie mehr Informationen hierüber
benötigen.</para>
</listitem>
<listitem>
<para>Lassen Sie den Test mindestens drei Mal laufen, besser
mehr als 20 Mal, sowohl
für <quote>vor</quote> als auch für
<quote>nach</quote> dem Code. Versuchen Sie abzuwechseln
(d.h. nicht erst 20 Mal <quote>vorher</quote> und dann 20
Mal <quote>nachher</quote>), dies ermöglicht,
umgebungsbedingte Effekte zu erkennen. Wechseln Sie nicht
1:1 ab, sondern 3:3; dies erlaubt,
Wechselwirkungseffekte zu erkennen.</para>
<para>Ein gutes Muster ist:
<literal>bababa{bbbaaa}*</literal>. Dies gibt Hinweise nach
den ersten 1+1-Läufen (sodass Sie den Test stoppen
können, falls er völlig daneben geht), Sie
können die Standardabweichung nach den ersten 3+3-Läufen
überprüfen (zeigt an, ob sich ein
längerer Lauf lohnt), später
Trends und Wechselwirkungen.</para>
</listitem>
<listitem>
<para>Benutzen Sie &man.ministat.1;, um
festzustellen, ob Ihre Ergebnisse signifikant sind.
Überlegen Sie sich, das Buch <quote>Cartoon guide to
statistics</quote> ISBN: 0062731025 zu kaufen. Es ist sehr
empfehlenswert, falls Sie Dinge wie Standardabweichung und
Studentsche t-Verteilung vergessen oder nie gelernt
haben.</para>
</listitem>
<listitem>
<para>Benutzen Sie keinen Hintergrund-&man.fsck.8;, wenn Sie
ihn nicht selbst testen
wollen. Schalten Sie auch <varname>background_fsck</varname>
in <filename>/etc/rc.conf</filename> aus, es sei denn der
Benchmark wird nicht mindestens 60+<quote>Laufzeit von
<command>fsck</command></quote> Sekunden nach Systemstart
gestartet, da &man.rc.8; startet und prüft, ob
<command>fsck</command> auf irgendeinem der Dateisysteme
laufen muss, wenn Hintergrund-<command>fsck</command>
eingeschaltet ist. Stellen Sie ebenfalls sicher, dass keine
Snapshots herumliegen, falls der Benchmark nicht ein Test
mit Snapshots ist.</para>
</listitem>
<listitem>
<para>Falls der Benchmark unerwartet schlechte Performance
zeigt, überprüfen Sie Dinge wie große Mengen
Interrupts von unerwarteten Quellen. Es gibt Berichte, dass
einige <acronym>ACPI</acronym>-Versionen sich <quote>daneben
benehmen</quote> und ein Übermaß an Interrupts
erzeugen. Um zu helfen, ungewöhnliche Testergebnisse zu
diagnostizieren, machen Sie ein paar Momentaufnahmen von
<command>vmstat -i</command> und suchen Sie nach
Ungewöhnlichem.</para>
</listitem>
<listitem>
<para>Gehen Sie mit Parametern zur Optimierung
von Kernel, Userland und Fehlersuche vorsichtig um.
Es passiert schnell, irgendetwas durchrutschen zu
lassen und dann später festzustellen, dass der Test
nicht das gleiche verglichen hat.</para>
</listitem>
<listitem>
<para>Erstellen Sie nie Benchmarks unter Verwendung der Kernel-Optionen
<literal>WITNESS</literal> und <literal>INVARIANTS</literal>,
wenn der Test nicht diese Merkmale selbst
untersuchen soll. <literal>WITNESS</literal> kann zu 400% und
mehr Performance-Abnahme führen. Ähnliches gilt
für Userland-&man.malloc.3;-Parameter, Voreinstellungen
hierbei unterscheiden sich bei -CURRENT von denen bei
Production-Releases.</para>
</listitem>
</itemizedlist>
</section>
</chapter>