MD3000i Performance-Test

Als sekundäres Storage-System für unsere Datenarchivierung und Backups haben wir uns kürzlich die ISCSI-basierte PowerVault MD3000i von DELL angeschafft. Bevor das System in den Livebetrieb übergeht wird es unterschiedlichen, internen Tests unterzogen. Die wichtigsten Erkenntnisse meines ersten Performancetests stelle ich in diesem Artikel und die detaillierten Ergebnisse im Techstories-Wiki vor.

Die MD3000i ist in diesem Test mit 8 x 1TB SATA-Festplatten im RAID-10 Verbund konfiguriert. Als weiteres Hardware-Equipment stehen zwei managebare Gigabit-Switches für ein dediziertes ISCSI-Netzwerk und zwei ähnliche Serversysteme mit Windows Server 2003 und CentOS 5.3 zur Verfügung. Die Server sind mit 2 x 1GBe (loadbalancing) und das Storage mit 2 x 2 x 1GBe (redundanter Controller und loadbalancing) angebunden. Genauere Informationen zur Hardware und zum Test-Aufbau findet sich im Wiki.

Unter Windows wurden die Performancetests mit IOMeter und ORION (Oracle I/O Calibration Tool) durchgeführt. Leider erzielten die Tests mit IOMeter unter Linux noch aus ungeklärten Gründen nur einen Bruchteil der Performancewerte unter Windows: z.B. 180MB/s sequentielles 32k-Lesen unter Windows vs. 40MB/s unter Linux. Erst mit einer Block-Größe von 1MB statt 32k konnte ein ähnlicher, sequentieller Durchsatz erreicht werden. Daher wurde unter Linux erst einmal nur mit bonnie++ und dd getestet werden.

Die MD3000i erzielte eine maximale sequentielle Leserate von 200MB/s (6414 IOPS x 32k), eine sequentielle Schreibrate von 125MB/s (4025 IOPS x 32k) und 685 IOPS bei 8k-Random-Zugriff mit 70% Leseanteil. Interessanter als die nominalen Ergebnisse dieser spezifischen Storage-Konfiguration waren jedoch die Auswirkungen auf die Performancewerte bei unterschiedlichen Test-Parameter: Zugriff auf Raw-Device oder NTFS/Ext3/XFS-Dateisystem, Zugriff mit mehreren offenen IOs und Threads, Aktivierung von Flow-Control und Jumbo-Frames im ISCSI-Netzwerks. Die wichtigsten Erkenntnisse im Überblick:

• Bei der Verwendung von NTFS mit 64k Clustergröße verringert sich die CPU-Belastung bei intensiven Schreibzugriffen zwischen 20 und 40%. Dabei verschlechtert sich die Performance bei Random-Zugriffen etwas (7%), der sequentielle Durchsatz bleibt konstant.
• Auch bei aktiviertem Flow-Control im ISCSI-Netzwerk nimmt die CPU-Belastung stark bei intensiven Schreibzugriffen ab (20-40%). Im Vergleich zu NTFS 64k bricht dabei jedoch die Performance bei Random- und sequentiellem Zugriff nicht ein, sondern steigt minimal an. Fazit: Beste Performance bei annehmbarer CPU-Belastung.
• Wird Jumbo-Frames im ISCSI-Netzwerk aktiviert, erhält man die geringste CPU-Belastung im gesamten Test: 13% geringer bei Random-Zugriff, 52% geringer bei seq. Lesen und 130% bei seq. Schreiben. Die Performance nimmt jedoch auch ab: 4,5% schlechtere Werte bei 32k seq. Lesen und 10% beim Random-Zugriff. Fazit: Geringste CPU-Belastung bei guter Performance.

Weitere Details und Testergebnisse unter Linux sind im Wiki-Dokument festgehalten.

Wenn es die Zeit zulässt, folgen noch Updates bezüglich einer weiteren Senkung der CPU-Belastung beim Einsatz von TOE (TCP Offload Engine) und Performance-Vergleichtests beim Einsatz von RAID-5/6 statt RAID-10.

Ausblick auf neue Blog-Themen:
In den nächsten Monaten wird das aufgebaute Hardware-Equipment für intensive Tests der drei großen Virtualisierungslösungen Citrix XenServer, Virtual Iron und VMWare ESX zum Einsatz kommen. Erste, unvollständige Grundlagen dazu finden sich hier.

HTML Parsen mit dem IPhone

Für ein aktuelles IPhone-Projekt musste ich eine große Webseite mit nicht wohlgeformten HTML-Code parsen und bin unvorhergesehen auf viele Probleme gestoßen. Begonnen habe ich mit den Hausmitteln der IPhone SDK, der Cocoa Objective-C Klasse NSXMLParser, die wie alle anderen verfügbaren Parser für das IPhone auf der C-Bibliothek libxml2 basiert. Der NSXMLParser gehört zu den SAX-Parsern (“Simple API for XML“), d.h. er durchläuft das XML-Dokument sequentiell und löst bei XML-Konstrukten, wie z.B. öffnenden oder schließenden Tags, bestimmte Ereignisse aus, die vom Programm ausgewertet werden können. Es stellte sich jedoch schnell heraus, dass NSXMLParser nur für die Verarbeitung von kleineren XML-Dokumenten geeignet ist und nur mit XHTML-Code zurecht kommt. Bei nicht wohlgeformten HTML-Code wurden Teile falsch oder gar nicht erkannt und in einigen Fällen kam es sogar zu Speicherzugriffsfehlern in der Klasse.

Als nächstes bin ich auf die DOM-Parser-Implementierung XPathQuery gestoßen. Im Vergleich zu SAX wird bei DOM (“Document Object Model“) das komplette Dokument eingelesen und eine Baumstruktur im Speicher aufgebaut, über die man auf die verschiedenen Knoten und Elemente des XML-Dokuments zugreifen kann. XPathQuery unterstützt neben XML explizit auch das Parsen von HTML und kommt auch mit nicht wohlgeformten HTML-Code zurecht. Doch erste Tests auf der IPhone Hardware machte schnell deutlich, dass das Erstellen eines DOM-Trees mit Objective-C Objekten für ein über 800kb großes HTML-Dokument mit 10MB Speicherverbrauch und über 15 Sekunden Parse-Zeit die falsche Wahl auf dem IPhone ist.

Nach weiteren DOM-basierten Parsern (Übersicht im Techstories-Wiki), die ich eventuell in einem späteren Blog-Eintrag vorstellen werde, bin ich schließlich auf die Klasse AQXMLParser aufmerksam geworden. AQXMLParser baut auf NSXMLParser auf und löst die folgenden Probleme von NSXMLParser:

• Inkrementelles Einlesen von XML-Dokumenten, dadurch geringerer Speicherverbrauch und Parsen während des Downloads möglich
• Parsen von nicht wohlgeformten HTML-Code

Leider ist aber auch diese Klasse nicht ganz fehlerfrei. Folgende Probleme konnte ich jedoch mit einem Patch beheben:

• Speicherzugriffsfehler beim Einlesen eines kompletten Dokuments
• Abbruch des kompletten Parse-Vorgangs bei Parser-Fehlern (ist jetzt über die Methode setAbortOnErrors konfigurierbar)

Mit der gepatchten AQXMLParser-Klasse steht eine performante und ressourcen- effektive Lösung für das Parsen von großen, nicht wohlgeformten HTML- und natürlich auch XML-Dokumenten auf dem IPhone zur Verfügung. Bei kleineren Dokumenten kommen jedoch auch DOM-basierte Parser in Frage, da sie meist einfacher zu implementieren sind.

Weitere Details und Beispiel Implementierungen finden sich im Wiki. Der Patch kann direkt hier heruntergeladen werden.