Schnittstellen Performance: Java File IO vs REST

Datenaustausch via Dateisystem oder doch besser REST, oder ? Davon handelt dieser kleine Artikel.

Das Dateisystem ist auch in Zeiten von Cloud und SOA noch immer eine beliebte Schnittstelle, um Daten zwischen Systemen auszutauschen. Oftmals handelt es sich um gewachsene Systeme und unter dem Motto „never change a running system“ – spricht auch erstmal nichts dagegen. Sobald die Systemlandschaft aber komplexer wird und die Nutzer über Performanceprobleme klagen, muss dieser technologische Ansatz auf den Prüfstand. Vielleicht gibt es auch beim Betrieb bereits Probleme, deren Ursache in der dateibasierten Schnittstelle verortet sein können.

Hier eine kleine Checkliste mit Punkten, die auf solche Schnittstellenproblemen hindeuten.

Meine Anwendungsarchitektur besteht aus verteilten Systemen.
Es ist ein hohes Maß an Ausfallsicherheit notwendig.
Systeme geraten öfters in einen inkonsistenten Zustand und müssen durchgestartet werden.
Verarbeitungen müssen in Echtzeit stattfinden, Antwortzeiten sind aber sehr lange.

Anwendungsarchitektur

Moderne Systemlandschaften bestehen oft nicht mehr nur aus einer DB und Application Server. Es sind vielmehr zahlreiche Systeme involviert: Von Benutzerverwaltung, über Bildbereitstellung und Zahlungssystemen, bis zu Ticketing- und Mailsystemen oder diverse CMSe.
Alles muss miteinander kommunizieren. Man würde auf der grünen Wiese hierfür höchstwahrscheinlich einen SOA Ansatz wählen mit den entsprechenden Technologien.
Kunden haben jedoch selten ungepflügte Äcker. Oft sind es Bestandssysteme, die irgendwann Probleme machen, da die Zeit die ursprüngliche ausgelegte Kapazität eingeholt hat.
Es kommt zu oben genannten Symptomen, die einfach nicht mehr tragbar sind.
Nun ist es schwer, alles wegzuwerfen und neu zu machen. Daher muss das System auf Bottlenecks analysiert werden, im ersten Schritt betrachtet man das Gesamtsystem, also die eingesetzte Schnittstellentechnologie.

Werden Daten mittels FileIO übertragen, müssen die zunächst in eine Verzeichnis geschrieben werden. Sobald der Empfänger festgestellt hat, das neue Daten da sind, müssen die gelesen werden. Hier finden also schreibend und lesende Zugriffe statt. Während diese in einem lokalen System noch tragbar wären, sieht das bei FileIO übers Netzwerk schon anders aus. Meistens gibt es NAS Systeme, über die der Datenstrom läuft, diese sind mittels NFS und CIFS eingebunden.
In diesen Fällen macht man bei Java die Rechnung ohne das Betriebssystem: Denn dieses sorgt durch eigene Caching Strategien für einen ordentlichen Overhead bei der Performance. Mit JRE6 dauert File IO übers Netzwerk bis zu 20 Mal länger würde der gleiche Aufruf via REST stattfinden. Mit Java 7 reduziert sich das zwar deutlich, steht aber mit 2-3 mal so lange noch immer nicht so gut da.

Um filebasierte Schnittstellen ausfallsicher zu machen, ist erhöhter Aufwand nötig. Es muss sichergestellt werden, dass die beteiligten System mit Dateiruinen zurechtkommen und bei Netzwerkwacklern wieder selbsttätig den Betrieb aufnehmen.

Als HTTP basierte Technik stellen diese Herausforderungen für REST (oder auch Webservices) kein Problem dar. Zwar müssen auch hier Netzwerktimeouts und HTTP Error Codes behandelt werden, doch REST selber gerät nicht in einen unbekannten Zustand wenn es zu unerwarteten Abbrüchen kommt.

Schlussendlich hat auch in Punkto Echtzeit REST die Nase vorne. Als synchrones Protokoll konzipiert, stellt HTTP hier den direktesten Weg zwischen zwei Systeme dar, inklusive Rückkanal.Eine Dateischnittstelle muss dies aufwändig nachbilden.

Fakten

Performancevergleiche zeigen auch ein eindeutiges Bild – neben FIleIO und REST wurde dabei auch Upload/Download via Servlet und HTTP Webserver getestet. Der Fokus soll hier aber bei FileIO/REST bleiben. Die Schaubilder zeigen auf der y-Achse die Dateigrößen in kb, die x-Achse die Zeit in Millisekunden. Die Testdaten wurden zufällig erzeugt, um Cachingeffekte zu minimieren. Es wurde Java7 eingesetzt. Mit Java8 und NIO wurden ebenfalls Tests durchgeführt – das Ergebniss bleibt im wesentlichen aber das gleiche.