Nach einer langen Zeit (über einem Jahr) war es mal wieder Zeit zu testen, wie es um die Performance meines NAS bzw dessen Verschlüsselung steht. Leider hat sich zu damals die Plattenconfiguration geändert, so dass man eigendlich die Performance nicht vergleichen kann. Jedoch war damals wie heute nicht der RAID-IO der limitierende Faktor sondern die Cipher-Performance. Wie damals kommt ein RAID5 als Storage-Basis zum Einsatzt. Diesmal nur 1GB statt 250GB Platten. Weiterhin werkelt ein 2.5GHz Intel Core2Duo samt 4GB Ram in dem Server.
Da auf dem Storage schon ein Haufen Daten liegen entfallen leider die Vergleichstest der anderen Cipher, da ein on-the-fly umschlüsseln nicht möglich ist und ich keine Lust hab 8 stunden zu warten um ein Full-Backup einzuspielen.
Zusammenfassung: Wie gehabt können Daten scheinbar schnell entschlüsselt als verschlüsselt werden. Was auch auffällt, dass die ersten drei Testwerte sehr viel schlechter sind als beim ersten Test. Das schiebe ich mal auf das initialisierte XFS Filesystem. Das FileSystem ist zu 55% gefüllt. Daher kommt es beim Write zu einer Lückensuche, die damals bei einem frisch aufgesetzten Filesystem nicht nötig war. Bei BlockRead und Rewrite zeigt sich dann, dass es Verbesserung in der Performance der Algorithmen gab. Leider scheint die Parallelisierung des AES-Algoritmus noch nicht wirklich weit voran geschritten zu sein. Ein CPU-Kern langweilt sich immer noch vollständig…
Wer unter WPF eigene Controls erzeugt wird sich früher oder später mit der Frage der Performance auseinander setzten müssen. Besonders wenn das eigene UserControl mehr als 100 mal auf die Oberfläche darstellt. Spätestens dann muss man sich gut überlegen, wo man in den WPF-ToolKit Baum einsteigt.
Zuerst muss man als alter DirectDraw oder WindowsForms Entwickler umdenken. Anders als früher zeichnet man nicht mehr „immidiate“. Früher wurde man vom Betriebssystem informiert, wenn sich was am Zeichenbereich geändert hat und man musste „mit der Hand am arm“ neuzeichnen. Bei WPF wird der Spieß umgedreht. Man übergibt dem WPF Subsystem eine Reihe von zu zeichnenden Objekten und wird dann nicht weiter belästigt. Das Subsystem kümmert sich um alles, was das Neuzeichnen, Überzeichnen und das Transformieren betrifft.
Die leichteste Komponente die man zeichnen kann ist eine irgendwie geartete Geometrie. Leicht im Sinne von Overhead, der vom WPF-Subsystem erzeugt wird. Will man „schnell“ viele ObjeKte Zeichnen ist es die einfachste Methode alles in einen DrawingContext/DrawingVisual zu zeichnen. Mittels ein oder mehrerer Geometries kann man die komplexesten Objekte zeichnen. Leider hat dieses Verfahren das Problem, dass man sich um alles selber kümmern muss. Es gitb keine „MouseEvents“ oder ähnliches für die Geometries. Desweiteren kann man ein DrawingVisual nur im ganzen neu zeichnen. Will man einzelne Bereiche aktualisieren muss das ganze Bild neu gezeichnet. Das kann bei vielen Objekten zu einem Problem werden.
Der bessere Weg ist da einen DrawingContainer zu nutzen. Dabei wird stellt jede darzustellende Objekt ein Geometrie dar, die in ihr eigenes DrawingVisual gezeichnet wird. Dieses wird dann in einen DrawingContainer eingebettet. Das erhöht den Overhead ein wenig, bietet dafür aber den Vorteil, dass einzelne Bereiche des Bildes neu gezeichnet werden können, ohne dass andere DrawingVisuals davon betroffen sind. Um HitTesting und „MouseEvents“ muss man sich erneut selber kümmern.
Kommt es auf Performance nicht an, kann man auch von einem UserControl oder ähnlichem ableiten und diesem ein DrawingVisual als Child verpassen. Hier hat man alle Vorzüge die das WPF so an EventHandling Bereit hält, leider geht damit auch ein erheblicher Performanceverlusst ein her.
Wenn man einen File-Server betreibt, so kann man unglaublich viel Zeit darin investieren, den Raid zu planen, die Verschlüsselung einzurichten und das Netzwerk zu tunen. All das nutzt aber nichts, wenn am Ende der Benutzer glaubt, die Bytes einzeln über die Leitung schieben zu müssen.
Dass kann bzw wird passieren, wenn man seinen File-Server verschlüsselt. Der tollste RAID bringt wenig, wenn er auf den CPU warten muss, weil dieser fröhlich am ent-/verschlüsseln ist. Hier liegt ein grundlegender Widerspruch zwischen zwei Anforderungen vor. Jeh stärker man die Verschlüsselung forciert, desto langsamer wird der Datenzugriff.
Die erreichten Werte skalieren dabei jedoch nicht wie erwartet. Und überhaupt fällt es im ersten Moment schwer, die wirklich wichtigen Parameter auszumachen. Zuallererst müssen die Rahmenparameter abgesteckt werden:
Wichtig ist die LAN-Anbindung. 100MBit/s oder 1GBit/s. Beides Transferraten sind wesentlich langsamer, als dass was fast alle RAIDs (auch Software RAIDs) Zustande bringen. Aus dem Stand schaffte mein Testsystem 251,59MByte/s (write) und 293,41MByte/s (read). An dieser Stelle sei darauf hingewiesen, dass man von Bits in Byte umrechnen muss. (1GBit/s=1024MBit/s = 128MByte).
Der zweite Rahmenparameter sind die Clients, bzw. deren Festplatten. Die maximale Transferrate ergibt sich aus der Lese/Schreibgeschwindigkeit dieser Komponente. In großen Netzwerken sollte kann man das getrost ignorieren, da immer mehrere Clients den Server ans Limit fahren. Im Privatgebrauch, mit weniger als fünf Clients, sollte man aber schon mal schauen wie viel Power man wirklich braucht. Dazu nimmt man seine „schnellste“ Kiste (in meinem Fall 60MByite/s Read/40MByte/s Write) und nimmt die mal 1.5. Das ist zwar kein wissenschaftlich ermittelter Wert, aber über den Daumen reicht das.
Neben diesen „harten“ Rahmenbedingungen gibt es noch eine Reihe weicher „Auswahlkriterieren“. Bei fast jedem Benchmarktool bekommt man verschiedene Werte der „Festplatte“ ausgewiesen. Sequenzjelles(Block) Lesen/Schreiben, zufälliges Lesen/schreiben und so weiter. Eine Fülle von Informationen von denen man nicht weiß, welcher Wert wichtiger ist. Zur Vereinfachung lässt sich sagen, dass bei einem Fileserver in 90% der Fälle das sequenzielle Lesen/Schreiben wichtiger ist.
Zum Testszenario: Alle Verschlüsselungs/Cipher-Algorithmen-Kombination musste ein 750GB Device verschlüsseln, wobei auch verschiedene Schlüssellängen durchprobiert wurden. Als überlagertes Dateisystem kam XFS zum Einsatz. Der CPU (ein 2.5GHz Intel Core 2 Duo) übernahm dabei nur die Krypto-Aufgaben. Der (Hardware) RAID-Controler war für die IO Zuständig. Die 4GB RAM kann man ausklammern, da der Benchmark (in diesem Fall bonnie++) bewusst den RAM umgeht. Bei einem Testfile von 8GByte Nutzt einem weder der 4GByte-RAM noch die 256 MByte Controller-Cache irgendwas. Was ja auch Sinn dieser Test ist. Das ganze lief unter einem 64 Bit Ubuntu 9.04
Zum Ergebnisdiagramm: Der RAID lieferte nativ (unverschlüsselt) 252 MByte/s (Block Write) und 293,41 MByte/s (Block Read). Dies ist nicht auf dem Diagramm zu sehen, weil dann die Skalierung unvorteilhaft geworden wäre. Die ersten 3 Testwerte stellen daher die „praktischen“ Referenzwerte dar. Als maximal physikalische Obergrenze steht dabei die 1GBits Ethernet Verbindung. In der Praxis bringt die es bei mir ungefähr auf 800 Mbit/s (100MByte/s), folglich sind alle IO-Bandbreiten, mit mehr Leistung sinnlos. Als zweiten Referenzwert hab ich die Festplattenleistung aller meiner Clients gemessen und deren Ergebnis gemittelt. Mehr Leistung als diese ist zwar nett, da dadurch mehrere Rechner gleichzeitig auf dem Server arbeiten können aber sonderlich viel mehr Leistung wird nicht gebraucht, da dass Netzwerk aus nicht mal 5 Rechnern besteht. Der dritte Referenzwert ist der Wert der (mich) am meisten überrascht hat. Es ist die Rohleistung die der Standard SMB-Client (libsmbclient 2:3.3.2-1ubuntu3.2) auf die Leitung bringt. Überraschend deswegen, weil er schneller schreiben als lesen kann. Ob dies an meiner Serverkonfig liegt, konnte ich noch nicht verifizieren.
Alle Tests fanden Donnerstag von 23 bis Freitag 2 Uhr statt.
Verschlüsselung Performance Statistik CPU Auslastung CPU Auslastung
Die Auswertung: Da der Referenzbalken der Unverschlüsselten Performance fehlt, sieht das Ergebnis Feld ganz brauchbar aus. Das täuscht. Als erstes fällt auf, dass sich alle Algoritmen-Mischungen ungefähr gleich geschlagen haben. In absoluten Zahlen ausgedrückt sieht das wie folgt aus:
Write Char: Der schlechteste Wert ist 66.25 MByte/s und erreicht somit noch immer 91% der nativen Leistung. Ach die Streuung ist vernachlässigbar, Zwischen dem schnellsten und langsamsten Algorithmus liegen gerade mal 3 MByte/s.
Write Block: Der eigentlich interessante Wert für einen Fileserver weißt die erste Überraschung auf. Hier bringt es der schnellte Algorithmus gerade mal auf 61% (152 KByte) der ursprünglichen Leistung. Die Streuung ist hier auch am größten. Zwischen den beiden Extremen liegen 60 KByte/s. Das ist gemessen am absoluten Leistungsverlust (99MByte/s) ein enormer Wert.
Rewrite: Hier zeigt sich wieder ein ähnliches Bild wie beim „Write Char“-Test. Das Ergebnisfeld ist dicht beieinander. Mit einem Maximalunterschied von 6KByte/s spielt es fast keine Rolle.
Read Char: Auch hier das gleiche Bild. Alle Algorithmen liegen dicht beieinander. Auch der Verlust hält sich in Grenzen. (7KByte/s)
Read Block: Die größte Überraschung am Schluss: Mit einem Leistungsverlust von fast 80% schlagen sich alle Algorithmen in dieser Disziplin schlecht. Zudem gibt es hier wieder nennenswerte Unterschiede zwischen den einzelnen Algorithmen.(20KByte/s bei einem absoluten Verlust von 230 KByte/s) Da dies eine Königsdisziplin der FileServer ist (Dateien ausliefern) gebietet es sich, hier genauer hin zuschauen.
Neben diesen Einzelwerten fällt auf, dass die Leistung der Algorithmen nicht skaliert wie man es erwartet. Das liegt zum einen daran, dass der absolute Verlust an der Dimensionierung der CPU im Vergleich zur nativen Leistung hängt. Auf Deutsch:Der CPU gibt die maximale IO-Geschwindigkeit an, ein Monster RAID + LowCost CPU ist blöd. Der RAID wird sich die ganze zeit langweilen, weil der CPU nur am Rödeln ist. Hier wird auch klar, dass nachrüsten von Speicher an so einer Leistungsgrenze wenig bringt. Der Flaschenhals ist die CPU. Dass sieht anders aus, wenn man einen Software- oder Fake-RAID benutzt. Zum anderen skallieren die Algorithmen selber nicht wie erwartet. Wenn ein Algorithmus gut im Random-Access ist, sagt das noch lange nichts über seine Leistung im Block-Lesen oder gar Schreiben aus. Dass Schreiboperationen performanter als Leseoperationen durchgeführt werden, entzieht sich komplett meiner Logik.
Neben diesen reinen Duschsatzzahlen war es interessant Festzustellen, dass alle Algorithmen aus CPU-Sicht gleich aufwändig sind. Die Auslastung lag fast immer am Limit. Auch wenn das CPU-Diagramm etwas anderes vermuten lässt. Im ersten Moment sieht es so aus, dass der CPU eine hohe IDLE-Rate hat (Pink+Türkies). Das ist aber nur die halbe Wahrheit. Besonders bei dem langen Block nach den Test (von 3 Bis 4 Uhr – hier wurden 180 GByte Backupdaten wieder auf den RAID aufgespielt) fällt auf, dass es faktisch nur noch drei Statie gibt, in dem sich der CPU befindet: IDLE, IOWAIT oder SYSTEM. Eigentlich müssten sich IOWAIT und SYSTEM zu 100% ergänzen. Der Grund für das IDLE ist einfach: Keine oder kaum Parallelisierung. Ein CPU hat sich immer gelangweilt. Das hat den Vorteil, dass das System trotz Vollast noch gute Antwortzeiten aufweist und einsatzfähig ist, kostet aber enorm an Durchsatz.
In hab mich für den aes-xts-plain mit einer Schlüssellänge von 256 entschieden. Da dieser die beste Block-Read/Write Performance hat. AES-ECB ist zwar nochmal eine ganze Ecke schneller (besonders beim lesenden Zugriff) jedoch ist dieser Algorithmus für eine reihe von Angriffen anfällig, die bis zur Extraktion der Krypto-Keys gehen.
[UPDATE] Nach der Veröffentlichung in den ubuntuusers-Foren hat mich Red Radish darauf hingewiesen, dass viele der hier genannten Verschlüsselungs-Algoritmen zwar möglich aber wenig sinnvoll sind. Leider ging das aus den Seiten die ich biss her gelesen hab nicht hervor. Die Anzahl der „sinnvollen“ Ciphers sind:
aes-ecb
aes-cbc-essiv:sha256
aes-lrw-benbi
aes-xts-plain
twofish-cbc-essiv:sha256
twofish-lrw-benbi
twofish-xts-plain
Danach sieht das Diagramm etwas übersichtlicher aus.
Sollte man mal in die Verlegenheit kommen, die Netzwerkperformance (Durchsatz und co) testen zu müssen, so liefert das CommandLine Tool Netperf gute Dienste. Unter Ubuntu kann man es mittels folgendem Befehl ohne weiteres installieren.
sudo aptitude install netperf
auf einem rechner startet man den Performance-Server.
netserver -4 -p
Das „-4“ sorgt dafür, dass nur auf IPV4 anfragen reagiert wird. Natürlich geht auch ein V6 für IP6 oder ganz weglassen für beides…
Auf der clientseite muss man nur noch den Test starten
netperf -4 -p -H
schon hat man schön übersichtlich die Leistung (s)eines Netzwerkes im Blick
