Nachrichtenkompression
PLANTA-Server und PLANTA-Client kommunizieren über ein XML-Protokoll miteinander. Dadurch ist eine wohldefinierte Schnittstelle gegeben, was stabile Interoperabilität gewährleistet.
Jedoch sind XML-Nachrichten - aufgrund des selbstbeschreibenden und menschenlesbaren Charakters der Sprache - in Relation zu der tatsächlichen Nutzdatenmenge sehr groß.
Dies ist in Intranetsituationen, bei denen eine performante Netzwerkinfrastruktur gegeben ist, ein geringes Problem.
Existieren jedoch Netzwerkengpässe zwischen Server und Client, so kann die Nachrichtengröße vor allem bei größeren Datenmengen zu deutlichen Performanceeinbußen führen.
Netzwerkengpässe dieser Art sind beispielsweise gegeben, wenn die Clients von Außenstellen über DSL-Verbindungen mit einem im zentralen Rechenzentrum betriebenen PLANTA-Server kommunizieren.
Da das XML-Format hohe Redundanzen enthält, kann Kompression die Nachrichtengröße deutlich reduzieren. Statt die XML-Nachrichten direkt über das Netzwerk zu senden, werden diese in PLANTA mit dem Deflate-Algorithmus komprimiert.
Einsparungen von mehr als 90 % bei der versendeten Datenmenge können durch die Kompression erzielt werden.
Die Effizienz des Algorithmus kann man über einen Kompressionsgrad einstellen.
Hier muss zwischen benötigter Rechenzeit und der resultierenden Nachrichtengröße abgewägt werden: bei geringem Kompressionsgrad wird wenig Rechenzeit benötigt, allerdings ist dann die Nachrichtengröße höher; bei hohem Kompressionsgrad gilt das Umgekehrte.
Implementierung und Konfiguration
Es ist naheliegend, Kompression auf gleicher Ebene wie Verschlüsselung einzusetzen.
Viele Implementierungen des TLS-Protokolls unterstützen die Kompression mittels zlib (Deflate).
Die .NET-Implementierung von TLS unterstützt dies jedoch nicht, so dass eine zusätzliche Kompressionsschicht notwendig wurde.
Sowohl Client als auch Server setzen hierzu das Deflate-Verfahren ein.
Die Konfiguration muss auf beiden Seiten erfolgen.
Bei Verbindung des Clients mit dem Server handeln die Kommunikationspartner aus, ob Kompression erfolgen soll.
Nur wenn Client und Server beide für die Kompression konfiguriert sind, wird nach der Verhandlung komprimiert kommuniziert.
Deflate erlaubt die Angabe eines Kompressionsgrades, der auf 0 - 9 eingestellt werden kann:
- 0: keine Kompression. Hier wird die zu übertragende Datenmenge größer aufgrund des zlib-Format-Overheads
- 1: schnellste Kompression
- 2 - 8: Zwischenlevel, mit Default-Level 6
- 9: beste Kompression
Bei Client und Server können die Kompressionsgrade unabhängig voneinander angegeben werden.
Grad 6 wird auch hier angenommen, wenn in der Konfigurationsdatei kein Kompressionsgrad angegeben ist.
Beispiel-Messungen
Die folgenden Grafiken verdeutlichen das Einsparungspotential durch Kompression.
Nur die Nutzdatengröße wird hier betrachtet; auf TCP-Paket-Ebene kann die bei Nutzung von Kompression geringere benötigte Paketanzahl zu weiterer Verbesserung des Datenvolumens führen.
Projektworkflow
In allen Testfällen wurde ein Demodatensystem verwendet.
Über den Benutzer R41 (Multiprojektmanager) wurde das Projekt 4711 ausgewählt.
Alle Module des Projektpanels wurden nun angewählt, um von jedem Modul Daten zu erhalten.
Danach wurde ein Statusbericht erstellt.
Der Client wurde anschließend geschlossen.
In der
ersten und
zweiten Abbildung ist auf der x-Achse die Anzahl der insgesamt vom Server versendeten Nachrichten aufgetragen. Diese variiert je nach Lauf, da der oben genannte Ablauf manuell durchgeführt und dabei nicht die gleiche Anzahl an Ereignissen ausgelöst wurde. Dies hat jedoch kaum Auswirkungen auf die Größe der gesendeten Daten, die auf der y-Achse aufgetragen ist.
Die in der ersten Abbildung gezeigten Kurven sind auch in der zweiten Abbildung enthalten, werden in der zweiten Abbildung jedoch weiteren Konfigurationen mit ausgewählten Kompressionsgraden gegenübergestellt.
Gesamtübertragungsvolumen unkomprimiert und komprimiert (Kompressionsgrad 9)
Vergleich bei Verwendung verschiedener Kompressionsgrade
Serverbasierte Hyperlinks
Bei serverbasierten Hyperlinks fällt eine größere Menge an Daten an, da diese Objekte (z.B. Word-Dokumente) aus der Datenbank gelesen und an den Client gesendet werden.
Hier ist im Allgemeinen nicht mit großen Einsparungen zu rechnen, da viele Dateitypen bereits intern komprimiert sind.
Allerdings werden die Binärdaten über eine Base64-Kodierung in der XML-Nachricht eingebettet, so dass 4/3 der tatsächlichen Datenmenge übertragen werden muss.
Daher ergibt sich auch hier ein Einsparungspotential durch Kompression, dass ca 1/4 der Datenmenge bei komprimierten Daten ergibt.
Bei unkomprimierten Dateien, wie beispielsweise Log-Dateien, ist ein weit höherer Anteil zu erzielen.
Kompressionsergebnis bei verschiedenen Dateitypen
Kompressionsszenarien
In den meisten Szenarien bietet sich Kompression an, da sie die übertragene Datenmenge deutlich reduziert. Zusätzliche Kompression kann bei Verwendung eines komprimierenden VPN-Tunnels unterbleiben, da hier die Kompression in der Verschlüsselungsschicht enthalten ist. Allerdings ist der zusätzliche Aufwand auch hier nicht in dem Maße relevant, dass ein Ausschalten der Kompression zwingend notwendig wäre. Ausschalten der Kompression kann auch nur für einzelne Clients durchgeführt werden, so dass beispielsweise ein Client in einer über ein komprimierendes VPN angebundenen Außenstelle keine Kompression verwendet, während einer in einer anderen Außenstelle komprimiert kommuniziert.
. 
svg 
