Der ndbd-Prozess hat eine Reihe von einfachen Konstrukten, um auf die Daten in einem MySQL Cluster zuzugreifen. Wir haben eine ganz einfache Benchmark erstellt, um die jeweilige Leistung dieser Konstrukte zu testen und herauszufinden, wie sich die verschiedenen Verbindungen zwischen den Knoten auf diese Leistung auswirken.

Es gibt vier Zugriffsmethoden:

Um die Grundleistung dieser Zugriffsmethoden testen zu können, haben wir eine Reihe von Benchmarks entwickelt. Eine davon, nämlich testReadPerf, testet einzeln und im Stapel übersandte Zugriffe über Primärschlüssel oder eindeutige Schlüssel. Diese Benchmark misst auch den Setup-Aufwand von Bereichsscans, indem sie Scans ausführt, die einen einzelnen Datensatz zurückliefern. Eine andere Variante dieser Benchmark holt mit einem Bereichsscan eine Menge von Datensätzen ab.

So können wir die Kosten eines einzelnen Schlüsselzugriffs und eines einzelnen Datensatzscans ermitteln und zusätzlich festellen, wie sich die Kommunikationsmedien bei welcher Zugriffsmethode auswirken.

In unseren Tests haben wir die Basis-Benchmarks sowohl für einen normalen Transporter mit TCP/IP-Sockets als auch für eine ähnliche Umgebung mit SCI Sockets ermittelt. Die Zahlen in der folgenden Tabelle gelten für kleinere Abfragen mit 20 Datensätzen pro Zugriff. Die Differenz zwischen seriellem und Stapelzugriff access schrumpft um den Faktor 3 bis 4, wenn stattdessen 2-Kbyte-Datensätze verwendet werden. SCI Sockets wurden nicht mit 2-Kbyte-Datensätzen getestet. Die Tests wurden auf einem Cluster mit 2 Datenknoten gefahren, der auf zwei Computern mit je zwei CPUs (AMD MP1900+-Prozessoren) residiert.

In einer anderen Testreihe haben wir die Leistung der SCI Sockets der des SCI Transporters und diese beiden wiederum der Leistung eines TCP/IP-Transporters gegenübergestellt. Alle diese Tests verwendeten Primärschlüsselzugriffe, entweder seriell und mit mehreren Threads oder mit mehreren Threads und im Stapel.

Die Tests haben gezeigt, dass SCI Sockets um rund 100 % schneller waren als TCP/IP. Der SCI Transporter war in den meisten Fällen schneller als SCI Sockets. Ein bemerkenswerter Fall trat bei einem Testprogramm mit vielen Threads auf: Hier zeigte sich, dass der SCI Transporter keine gute Leistung brachte, wenn er für den mysqld-Prozess benutzt wird.

Insgesamt zeigen unsere Tests, dass SCI Sockets in den meisten Benchmarks rund 100 % schneller sind als TCP/IP, außer in seltenen Fällen, in denen es nicht auf die Geschwindigkeit der Kommunikation ankommt. Dies kann der Fall sein, wenn die meiste Verarbeitungszeit für Scanfilter verbraucht wird oder wenn sehr große Stapel von Primärschlüsselzugriffen zustande kommen. In diesem Fall macht die CPU-Last der ndbd-Prozesse einen großen Teil des Aufwands aus.

Eine Verwendung des SCI Transporters anstelle von SCI Sockets ist nur für die Kommunikation zwischen ndbd-Prozessen interessant. Der SCI Transporter ist jedoch auch eine Option, wenn eine CPU für den ndbd-Prozess dediziert werden kann, da der SCI Transporter dafür sorgen kann, dass dieser Prozess niemals schläft. Außerdem ist es wichtig, zu gewährleisten, dass die Priorität des ndbd-Prozesses so eingestellt wird, dass er auch nach langem Laufen seine Priorität nicht einbüßt. Dies kann in Linux 2.6 durch das Sperren von Prozessen in CPUs getan werden. Wenn eine solche Konfiguration machbar ist, legt der ndbd-Prozess im Vergleich zu einer Lösung mit SCI Sockets um 10 bis 70 % zu. (Die größeren Zahlen kommen bei Updates und möglicherweise auch bei Parallelscans zustande.)

Es gibt noch mehrere andere optimierte Socketimplementierungen für Computer-Cluster, darunter Myrinet, Gigabit Ethernet, Infiniband und die VIA-Schnittstelle. Wir haben MySQL Cluster bisher jedoch nur mit SCI Sockets getestet. Unter Abschnitt 16.7.1, „Konfiguration von MySQL Cluster für SCI Sockets“, erfahren Sie, wie Sie SCI Sockets mit normalem TCP/IP für MySQL Cluster einrichten.