Seite 3: Vor- und Nachteile eines Application Server

Inhaltsverzeichnis

Vor- und Nachteile eines Application Server

In vielen den Einsatz von WCF diskutierenden Fällen geht es gar nicht um die Kopplung zweier unabhängigen Anwendungen. Vielmehr geht es um die Frage, ob man eine Anwendung aus zwei physikalischen Schichten (Client – Datenbank, alias "2-Tier") oder drei physikalischen Schichten (Client – Application Server – Datenbank, alias "3-Tier") aufbauen möchte. Nur im zweiten Fall braucht man WCF, denn bei zwei physikalischen Schichten kann der Client direkt über die datenbankeigenen Protokolle mit dem Datenbankserver reden, etwa über Tabular Data Stream (TDS) mit Microsofts SQL Server. Die Kommunikation ist in den ADO.NET-Datenbank-Providern gekapselt.

Gerade im deutschen Sprachraum fällt es IT-Experten bei dem Themenkomplex oft schwer, eine gemeinsame Sprache zu finden, denn "Schicht" ist doppeldeutig. Die einen verstehen unter "Schicht" eine rein logische Trennung (im Englischen "Layer"), die anderen meinen damit eine physikalische Trennung ("Tier"), siehe Abbildung 2. Der Autor des Artikels war letztens wieder Zeuge (und Opfer) der Aussage eines "strategischen" IT-Beraters, der verkündete: "Heutzutage sind 3-Schicht-Anwendungen absolute Pflicht, die skalieren besser." Während der Autor die logische Schichtentrennung nicht in Frage stellen möchte, ist er skeptisch in Bezug auf eine so generelle Befürwortung der physikalischen Trennung, nur weil sie "modern" ist. Bevor man sich für das 3-Tier-Modell mit Application-Server-Modell als "Middle-Tier" entscheidet, sollte man die Vor- und Nachteile durchdenken.

Ein Application Server kann rechenintensive und lang andauernde Operationen auslagern, die sonst den Client blockieren würden. Ebenso dient er der Zwischenspeicherung (Caching) von Daten, um die Anzahl der Zugriffe auf die Datenbank zu reduzieren. Wenn die Leistung nicht mehr ausreicht, kann man einfach einen neuen Anwendungsserver dazustellen.

Unterschiedliche Meinungen gibt es dazu, wie viele "Tiers" eine klassische serverseitige Webanwendung mit Webbrowser, Webserver und Datenbank hat. Für die einen ist das schon 3-Tier, für andere wird es erst dazu, wenn den Webserver und die Datenbank noch ein Application Server trennt. Auch ohne ihn kann man in dem Szenario durch weitere Webserver skalieren. Mit einem Anwendungsserver ist die Flexibilität aber größer, denn es lässt sich in Abhängigkeit davon skalieren, ob der Engpass das Rendering der Webseiten oder die Verarbeitung im Hintergrund ist.

Application Server bilden zudem eine Sicherheitsgrenze zwischen Client und Datenbank. Das ist nicht nur in Internet-Szenarien relevant, in denen im Fall der Kompromittierung des Webservers ein Application Server eine zusätzliche Schutzmauer vor der Datenbank bildet. Auch in klassischen Desktop-Anwendungen kann man die Datenbank mit einem Application Server vor dem direkten Zugriff der Clients besser abschotten.

Messung der Leistungseinbußen

Auf der Negativseite steht neben einem viel höheren Entwicklungsaufwand vor allem der zusätzliche Kommunikations-Overhead, den der Einsatz des Anwendungsservers überhaupt erst auslöst. Ein erheblicher Overhead entsteht bei jedem verteilten System, egal welches Framework und welches Protokoll man einsetzt. Im konkreten Fall ist die Größenordnung des Overheads für WCF aufzuzeigen.

Für die Messungen kommt das von dem Autor entwickelte "WCF Barometer" zum Einsatz. 100 Datenbankzugriffe, bei denen sich je 1000 Datensätze (je 12 Spalten, nur elementare Datentypen) aus einer Datenbanktabelle mit 10.000 Datensätzen abholen lassen, dauern rund eine Sekunde, wenn der Client direkt auf das Datenbanksystem zugreifen kann (Abbildung 3).

Schaltet man einen Application Server zwischen den Client und die Datenbank, dauert die gleiche Kommunikation das Elffache (!) länger (siehe Abbildung 4).

Das ist der Overhead für den zusätzlichen Netzverkehr. Der Faktor steigt abermals, wenn man nicht TCP, sondern HTTP als Transportprotokoll einsetzt (siehe Tabelle 3).

	Alle Prozesse auf einem System	Verteilungsmodell 1	Verteilungsmodell 2	Verteilungsmodell 3
Client	Computer 1	Computer 1	Computer 1	Computer 1
Server	Computer 1	Computer 1	Computer 2	Computer 2
Datenbank	Computer 1	Computer 2	Computer 2	Computer 3
2-Tier (TDS)	1033	1082	1082	1082
WCF Named Pipes/binär	9603	9732	n/a (*)	n/a (*)
WCF TCP/binär	9612	9715	11586	12476
WCF HTTP/SOAP	11080	11192	13981	14099

Tabelle 3: Ausführungsdauer für das Lesen von 100 mal 1000 Datensätzen in unterschiedlichen Szenarien.
(*) Mit Named Pipes kann man in WCF nur Prozesse auf dem gleichen System aufrufen.

Den Verzögerungsfaktor kann ein Application Server nicht mehr hereinholen. Abbildung 5 zeigt, dass die Dauer bei 9,5 Sekunden liegt, wenn der Anwendungsserver nur beim ersten Mal die Daten vom Datenbankserver holt und bei den 99 folgenden Aufrufen nur noch die Daten aus seinem Zwischenspeicher im RAM weiterreicht. Er kann allenfalls punkten, wenn eine rechenintensive Verarbeitung hinzukommt und sich viele Daten zwischenspeichern lassen, deren Abholung aus der Datenbank zeitaufwendig ist (etwa wegen vieler Joins). Zu erwägen ist auch eine hybride Architektur, die den Application Server nicht generell für den Zugriff auf Daten zwischenschaltet, sondern nur bei ausgewählten, lang dauernden Vorgänge zum Einsatz kommt.