Apps schneller machen

Während wir die Rechenzentren immer weiter zerstören, indem wir Anwendungen und die Netzwerke, von denen sie abhängen, zerstören, bleibt ein Aphorismus aus der Geschäftswelt weiterhin wahr: Geschwindigkeit ist König. Die Leistung bleibt ein Problem auf Unternehmensebene, das sich auf alles auswirkt, vom Umsatz bis zur Produktivität, und manchmal auch auf das Endergebnis einwirkt.

Ein kürzlich erschienener Artikel auf DZone mit dem Titel „Wie schnell sind Web-Anwendungen im Jahr 2016? “ befasste sich eingehend mit einigen Einzelheiten hinsichtlich der Leistung und stellte fest, dass „bei einer typischen Web-Anwendung 4,2 % der Transaktionen abgebrochen werden.“ Dies basiert auf „fünf Milliarden Benutzerinteraktionen mit 500 verschiedenen webbasierten Anwendungen“.

Wie sich dies in Dollar auswirkt und auf Gewinn oder Produktivität auswirkt, hängt natürlich vom Geschäftsmodell ab. Dies könnte Millionen oder Milliarden Dollar oder verlorene Stunden bedeuten und den Ärger der Kunden über die längeren Gesprächszeiten nach sich ziehen.

Ungeachtet dessen bleibt die Leistung sowohl für Entwickler als auch für den Betrieb ein wichtiger Aspekt. Und mit Betrieb meine ich den gesamten Betrieb – Infrastruktur, Netzwerk, Speicher und Sicherheit. Unsere jüngste Umfrage zum Stand der Anwendungsbereitstellung bestätigte erneut die in allen IT-Rollen vertretene Ansicht, dass Leistung von entscheidender Bedeutung ist. Es war am unwahrscheinlichsten, dass zugunsten einer besseren Sicherheit darauf verzichtet würde (nur 9 % würden einen solchen Kompromiss eingehen) und 14 % der Befragten nannten dies als eine erhebliche Herausforderung bei Multi-Cloud-Implementierungen.

Trotzdem gaben nur 38 % an, dass sie jetzt App-Beschleunigungsdienste nutzen, und nur 22 % planten die Implementierung im nächsten Jahr. Etwas überraschend gaben 40 % an, dass sie keine Pläne hätten, App-Beschleunigung einzusetzen oder zu verwenden.

Dies kann daran liegen, dass die Vorstellung, was „App-Beschleunigung“ bedeutet, etwas unklar ist. Und zwar nicht wegen „der Cloud“, sondern weil sie sich im Laufe der Jahre von QoS über browserbasierte Delta-Aktualisierungen und Caches bis hin zu sogenannten Anwendungs-Frontends (AFE) weiterentwickelt und gewandelt hat, die in Wirklichkeit spezialisierte Proxys mit sehr leistungsorientierten Funktionen sind.

Wenn wir „App-Beschleunigung“ denken, denken wir meistens an Komprimierung und Caching, Minimierung und Bildoptimierung. Wir betrachten Protokolloptimierungen nicht als Teil der „Wir brauchen Warp 9, Scotty“-Mentalität, die heutzutage die Erwartungen von Unternehmen und Benutzern durchdringt. Aber das sollten wir.

Oh, wir sehen, dass Protocol Offloading heutzutage häufig verwendet wird. Im Laufe des Jahres 2015 stieg die Nutzung von clientseitigem SSL-Offload (die Seite, die sicheres HTTP mit Benutzern verwaltet) von knapp 80 % auf fast 100 %. Dies überrascht nicht, wenn man bedenkt, dass der sicheren Kommunikation durch Initiativen wie „Let’s Encrypt!“ und „SSL Everywhere“ zunehmend Aufmerksamkeit gewidmet wird. SSL/TLS beeinträchtigt die Leistung (und zwar nicht im positiven Sinne), insbesondere bei zunehmender Belastung. Das Auslagern auf einen leistungsfähigen Proxy ist sinnvoll und wir sehen, dass Unternehmen genau das tun, um die Leistungseinbußen auszugleichen, die durch die Sicherung aller Komponenten entstehen.

Allerdings sehen wir auf der Serverseite des Backends keinen vergleichbaren Anstieg. Der Einsatz von TCP-Multiplexing zur Verbesserung der Leistung (und gleichzeitigen Erhöhung der Ressourcenkapazität) hat sich im letzten Jahr nicht wesentlich verändert. Knapp die Hälfte (durchgängig etwa 46 %) der Organisationen nutzt diese unbesungene Optimierungstechnik.

Das ist beängstigend, wenn man bedenkt, dass viele dieser Organisationen derzeit unter dem Containerfieber leiden.

Warum ist es beängstigend? Ich sage Ihnen, warum … Es ist zwar durchaus möglich, dass Unternehmen durch die Virtualisierung den TCP-Stack jeder Instanz optimieren konnten, um die höchstmögliche Leistung pro App sicherzustellen, doch die Einführung von Containern stellt dieses Modell in Frage. Das liegt daran, dass Container einen einzigen Netzwerkstapel gemeinsam nutzen. Die Optimierung für eine in einem Container bereitgestellte App garantiert nicht die beste Konfiguration für eine andere App in einem anderen Container auf demselben Host .

Da TCP-basierte Optimierungen wie TCP-Multiplexing auf der Protokollebene ausgeführt werden, sind sie wie Honigdachse. Es ist ihnen egal, ob sich die App in einem Container, einer virtuellen Maschine oder nackt auf einer Webplattform befindet. Sie optimieren die Verbindung und verbessern die Leistung, unabhängig davon, wie und wo die App bereitgestellt wird. Solche Dienste kümmern sich nur um das Protokoll und nutzen die Trennung von Client- und Serverseite, um zusätzlich sicherzustellen, dass die Clientseite für den Client und die Serverseite für die App optimiert ist. Das bedeutet zweifache Leistungsverbesserungen.

Verstehen Sie mich nicht falsch: Herkömmliche Dienste und Techniken zur App-Beschleunigung sind großartig, und wie Sie dem mehrfarbigen Diagramm oben entnehmen können, nutzen Unternehmen sie alle , um die Leistung ihrer Anwendungen zu verbessern. Es kann jedoch noch mehr getan werden, und wie die oben genannten Leistungsdaten zeigen, ist es sogar mehr, als getan werden sollte.

Es ist eine gute Idee, sich Ihren Proxy (den Sie wahrscheinlich nur zum Lastenausgleich verwenden) anzusehen und herauszufinden, ob er mehr für die Leistung Ihrer App tun kann, als Sie derzeit einsetzen.

Informieren Sie sich, wie F5 Apps schneller, intelligenter und sicherer macht.