Die dunkle Seite der Non-Blocking I/O

von Hubert Schmid vom 2014-02-02

Non-Blocking I/O and single-threaded Event Loop: Um dieses Programmiermodell ist in den letzten Jahren ein wahrhafter Hype entstanden, der zahlreiche neue Frameworks und Laufzeitumgebungen hervorgebracht hat. Zweifelsohne bieten solche Architekturen einige Vorteile, um mehrere Millionen TCP-Verbindungen gleichzeitig zu verarbeiten. Doch bei aller Euphorie sollte man sich stets bewusst sein: Wo viel Licht ist, ist starker Schatten.

Im Falle der Non-Blocking I/O reicht dafür einfach ein Blick zurück. Bis Mitte der neunziger Jahre war dieses Programmiermodell nämlich schon einmal sehr verbreitet für Netzwerkanwendungen – um nicht zu sagen vorherrschend. Doch mit der Jahrtausendwende hat es signifikant an Einfluss verloren. Für diesen Rückzug gab es gute Gründe, die noch heute fast genauso gelten. Diese Probleme sollte man sich vor Augen führen, falls man vor der Entscheidung für oder wider asynchrone Programmierung steht.

Non-Blocking I/O eignet sich ausgezeichnet für Anwendungen, die gleichzeitig mehrere hunderttausend TCP-Verbindungen verarbeiten und primär Netzwerk-Funktionalität realisieren. Typische Beispiele sind Forward und Reverse Proxies sowie Message Oriented Middleware (ohne Persistenz). Falls jedoch mehr Funktionalität benötigt wird, zeigen sich schnell die Schattenseiten: Die Komplexität steigt und die Performance bricht ein. Darum sollte man sich gut überlegen, ob sich dieser Weg lohnt.