====== Linux Benchmarks & Test tools ======
auch unter Linux gibt es natürlich eine gute Auswahl an Benchmarks, also Programme zum testen der Hardware auf "Flaschenhälse".


[[http://ltp.sourceforge.net/tooltable.php|Linux Test Tools]] - gute Übersicht nach Kategorien
[[http://lbs.sourceforge.net/|Linux Benchmark Suite Homepage]]
[[http://tldp.org/HOWTO/Benchmarking-HOWTO.html|Linux Benchmarking HOWTO]]


===== Test-suiten =====
  * [[http://www.phoronix-test-suite.com/|Phoronix Test Suite]], [[http://www.phoronix.com/scan.php?page=article&item=phoronix_pts&num=1|Phoronix Test Suite Released]]
  * [[http://www.netlib.org/benchmark/hpl/|Linpack]]

===== I/O =====

  * [[http://linux.inet.hr/how_fast_is_your_disk.html|How fast is your disk?]]
  * **tiobench** : für I/O- und Multitheading-Benchmarking
  * [[http://sourceforge.net/projects/sysbench/|sysbench]] (Realistische I/O-Load-Messung mit Unterstützung der [[datenbanken:mysql|MySQL-Datenbank]]) siehe auch:  [[http://www.randombugs.com/linux/compiling-sysbench-0412-debian.html|Compiling sysbench 0.4.12 for Debian]] und [[http://www.mysqlperformanceblog.com/2008/03/05/evaluating-io-subsystem-performance-for-mysql-needs/|Evaluating IO subsystem performance for MySQL Needs]]

other:
  * dbench (synthetisch)
  * [[http://www.netapp.com/tech_library/postmark.html|postmark]] (gibts auch für NT): geeignet für kleine Dateien (mail und news-Server)

Je nach Benchmark ist ggf. das Löschen der Caches sinnvoll:
<file>
drop_caches

Writing to this will cause the kernel to drop clean caches, dentries and
inodes from memory, causing that memory to become free.

To free pagecache:
    echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
    echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
    echo 3 > /proc/sys/vm/drop_caches

As this is a non-destructive operation and dirty objects are not freeable, the
user should run `sync' first.
</file>

==== dbench ====

  dbench 10 -t 60 -c results.txt
  
==== dd ====
funktioniert immer, für sequentielle Schreib/Lesetests ok.

<code bash>dd if=/dev/zero of=/ziel/testfile.dd bs=1000M count=1 oflag=direct</code>

Mit Zufallsdaten um Kompressions-/dedup-Effekte auszuschließen (z.B. bei SSDs):
<code bash>sudo dd if=/dev/urandom of=randfile bs=1M count=1024 && sync
sudo dd if=randfile of=/dev/ZIEL bs=4k count=100000 oflag=direct,dsync</code>
  
==== fio ====

<code bash>sudo fio --filename=/dev/ZIEL --size=20G --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=Schreibtest</code>

siehe "man fio", wichtig sind z.B. --direct für O_DIRECT-Zugriff (ohne Kernel page cache) und --sync für syncrone (O_DSYNC)-Zugriff um Schreibcaches abzuschalten.

==== IOMeter ====
IOMeter ist ein Festplattenbenchmark, der neue Entwicklungen (z.B. Dualcore und NCQ von Sata) besser berücksichtigt.
[[http://www.iometer.org/doc/downloads.html|IOMeter Download]]

==== hdparm-test ====
mit dem Standard-tool hdparm kann man die Interfacegeschwindigkeit und eine groben Geschwindigkeitstest machen. Dabei werden aber nicht unterschiedliche Zonen bewertet.

  sudo hdparm -T /dev/hda
bzw.
  sudo hdparm -t /dev/hda
(hda ändern auf anderen Wert wenn nötig)
siehe [[http://www.die.net/doc/linux/man/man8/hdparm.8.html|hdparm Handbuch]]

==== bonnie++ ====

bonnie++ start beim Aufruf einen Festplattentest im aktuellen Verzeichnis und gibt dann auf der Standardausgabe einen Report aus, den man mit bon_csv2html zu einer html-Datei verarbeiten kann. Dazu wird/werden die letzten Zeile(n) ausgewertet.

Bei einem Server mit 32GB RAM und Benutzer "benchuser" :

  bonnie++ -r 32768 -u benchuser > output.txt

Mehrere Pluszeichen weisen darauf hin das der Testlauf zu schnell fertig war um präzise Messergebnise zu erhalten. Es muss mit ''-n'' die Anzahl der Dateien hochgesetzt werden.

  bonnie++ -r 32768 -n 4 -u benchuser > output.txt

Einen einzelnen Testlauf kann man durch Pipes direkt als html-Datei ausgeben lassen:
  bonnie++ | tail -n 1 | bon_csv2html > report.html
bei umfangreichen Testläufen sollte man sich die Ergebnisse abspeichern und kann sie dann später verarbeiten (etwa so: ''bonnie++ > bonnie-report.txt''). Man kann sich die Ergebnisse auch als Textdatei aufbereiten lassen (mit csv2txt).

Wichtig sind bei den Ausgaben von bonnie++ dabei immer die Zeilen am Ende (im CSV-Format) die in etwa so aussehen:
<file>
Rechnername,3G,16310,45,26006,15,15854,5,19301,50,32735,6,131.5,0,16,+++++,+++,+++++,+++,30870,82,29483,82,+++++,+++,23010,61
</file>
wobei die Tests (bzw. die Daten) mit "+++" nicht aussagekräftig genug waren.

Die Optionen (Anzahl der Testläufe  etc.) findet man im Handbuch (''man bonnie++'').

[[http://www.linux.com/feature/139742|Using Bonnie++ for filesystem performance benchmarking]]

==== iozone3 ====

[[http://www.linux.com/feature/139744|IOzone for filesystem performance benchmarking]]




===== CPU =====

===== Mailserver =====
[[http://www.linux-magazin.de/heft_abo/ausgaben/2006/12/post_belastungsprobe?special=Groupware&category=16633|Mit dem Mailserver-Benchmark Postal Engpässen auf der Spur - Post-Belastungsprobe]] 


===== Netzwerk =====

  * netperf
  * tbench (im dbench-Paket)
  * [[http://www.heise.de/software/download/netio/2155|netio]] (Protokolle: TCP/UDP/NetBIOS)
  * [[http://sourceforge.net/projects/iperf/|iperf]] / [[http://sourceforge.net/project/showfiles.php?group_id=128336&package_id=268197|jperf (plattformunabhängige Java-Variante)]]
    * Aufruf **Server**: <code>iperf -s</code> (wartet per default auf Port 5001 auf Verbindungen
    * Aufruf **Client**: z.B.<code>iperf -P 1 -i 1 -p 5001 -w 56K -f k -t 10 -c SERVER-IP</code>

:!: Zwei Netzwerkkarten im gleichen Server zu testen ist (ohne weitere Verrenkungen) nicht möglich, der Kernel erkennt das dies ineffizient ist. Dennoch gibt es [[http://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface|Lösungen zu diesem "Problem"]], getestet habe ich [[http://serverfault.com/a/309442|diese Lösung]].
==== DNS ====

[[ftp://ftp.nominum.com/pub/nominum/dnsperf/|dnsperf]] ([[http://snobbycloud.blogspot.de/2012/07/installing-dnsperf-to-ubuntu-1204.html|muss kompiliert werden]])

==== NFS ====
  * nhfsstone

==== SMTP ====
  * [[http://www.coker.com.au/postal/|postal]]
  * [[http://www.slamd.com/|SLAMD Distributed Load Generation Engine]]
  * [[http://www.postfix.org/smtp-source.1.html|smtp-source]] (ein SMTP/LMTP Nachrichtengenerator) und [[http://www.postfix.org/smtp-sink.1.html|smtp-sink (nimmt Nachrichten an und verwirft diese)]] von Wietse Venema (siehe http://www.postfix.org/TUNING_README.html)

**smtp-sink Beispiel**: Der Rechner "blackhole.domain.tld" soll auf Port 25 (SMTP) 80000 mails entgegennehmen (und verwerfen). smtp-sink läuft als Benutzer "maildrop", da root nicht erlaubt ist.

<code bash>smtp-sink -u maildrop -c blackhole.domain.tld:25 80000</code>
==== HTTP ====
  * [[http://httpd.apache.org/docs/1.3/programs/ab.html|Apache Bench (ab): Apache Bestandteil]]
z. B. mit 10 konkurrierenden Verbindungen und 50 Anfragen:
<code>ab -n 50 -c 10 $URL</code>
  * siege 
  * httperf (bisher nicht in [[debian:Debian]] stable sondern nur in testing + bei Ubuntu enthalten)
  * [[http://jakarta.apache.org/jmeter/|Jmeter]] 
  * [[http://www.paessler.com/webstress|Webstress (Windows)]]
  * [[http://www.xenoclast.org/doc/benchmark/HTTP-benchmarking-HOWTO/|The Linux HTTP Benchmarking HOWTO]]

===== X-Server =====
  * xengine



===== Stresstests =====
  * zum belasten der CPU (prüfen von Systemstabilität) eignet sich cpuburn ganz gut.
  * contest: Kernelkompilationstests, eine ziemliche reale Aufgabe