Es scheint Jahrzehnte her zu sein, dass ich als Softwareentwickler bei Autodesk tätig war und die treibende Kraft hinter der CUI-Funktion in AutoCAD war.
Für diejenigen unter Ihnen, die sich nicht so weit zurückerinnern können: Mit dieser Funktion wurde eine neue Benutzeroberfläche für die Anpassung der AutoCAD-Symbolleisten und -Menüs eingeführt. Die ersten Versionen waren etwas holprig, aber schließlich entwickelte sich diese Funktion zu einem soliden Bestandteil von AutoCAD.
Eine der Hauptbeschwerden in der ersten AutoCAD-Version war, dass der Dialog zu langsam reagierte. Bei meinen Nachforschungen fand ich heraus, dass alles, was länger als 800 Millisekunden dauerte, für den Benutzer eine spürbare Verzögerung darstellte. Ich hatte die Aufgabe, die Startzeit des Dialogs von 1500 ms auf 800 ms zu reduzieren.
Ich dachte: "Wirklich? Werden 700 ms im Leben von irgendjemandem einen bedeutenden Unterschied machen?"
Übrigens habe ich dieses spezielle Ziel der Latenzreduzierung erreicht, und das war der Anfang vom Ende meiner Karriere in der Softwareentwicklung... aber das ist eine Geschichte für einen anderen Tag 
.
Im Jahr 2014 holte mich bat365 an Bord, um die Unterstützung für Anwendungen zu verbessern, die in der AEC-Branche häufig verwendet werden. Als ich mehr über die Funktionsweise von bat365 erfuhr, sprachen die Leute immer wieder über WAN-Latenz, die langsame Netzwerkleistung von AutoCAD und wie sie versuchten, die Übertragungszeiten um 100 ms zu verkürzen. Werden 100 ms für irgendjemanden einen signifikanten Unterschied ausmachen?"
Die Realität sieht so aus, dass alles eine Rolle spielt. Was wie kleine Zeitabschnitte aussieht, kann sich im Laufe eines Jahres zu erheblichen Verzögerungen summieren, die einen beträchtlichen Betrag kosten - vor allem, wenn man die abrechenbaren Stunden berücksichtigt. Selbst kleine Verzögerungen, die regelmäßig oder zu ungünstigen Zeiten auftreten, können bei den Endnutzern zu Frustration führen.
Warum die Latenz einen so großen Einfluss hat
Als bat365 anfing, AutoCAD-Dateien zu unterstützen, hatten die Firmen, die sich an bat365 wandten, schon seit Jahren versucht, das Öffnen von DWG-Dateien über das WAN zu bewerkstelligen.
Die Tendenz der AEC-Firmen, durch Übernahmen zu wachsen, hat oft zu mehreren Niederlassungen geführt, und es ist nur logisch, dass sie in der Lage sein wollten, Mitarbeiter mit spezialisiertem Fachwissen in Projekte einzubinden, wann immer sie sie brauchten, unabhängig davon, wo sie sich befanden.
Die gängige Meinung war damals, dass DWG-Dateien groß seien und man daher einfach mehr Bandbreite für die Übertragung der großen Dateien benötige. Als das nicht half, versuchte man es mit WAN-Beschleunigern, aber es wurde nicht viel besser.
Als bat365 die Aktivitäten analysierte, stellten wir fest, dass der größte Teil der Zeit, die für das Öffnen von Dateien aufgewendet wurde, nicht für die Übertragung der Daten verwendet wurde. Der größte Teil der Zeit entfiel auf die vielen Dateiaufrufe, die über eine große Entfernung erfolgen mussten.
Wenn eine Anwendung wie AutoCAD eine DWG-Datei öffnet, sind die benötigten Daten nicht alle in dieser einen Datei enthalten. Vielmehr müssen viele, viele unterstützende Dateien geöffnet werden, z. B. Schriftarten, Linientypen und Formdateien.
Hinzu kommt der Suchpfad von AutoCAD, der an vielen Stellen nach Unterstützungsdateien sucht.
Hinzu kommt noch die Anzahl der Anrufe, die Windows für jede geöffnete Datei zwischen dem Client-Rechner und dem Server tätigt.
Dazu kommen noch alle xrefs, die einfach nur andere DWGs sind, die auch Schriftarten, Linientypen und Formen öffnen.
Jetzt können Sie sehen, wie das Öffnen einer DWG-Datei Folgendes bewirkt:
1 DWG X 20 Unterstützungsdateien X 5 Suchpfade X 20 Windows-Aufrufe X 10 xrefs = 20.000 Transaktionen!
Wenn Sie eine DWG-Datei öffnen, bei der sich der Client-Computer und der Server in einem LAN mit einer Latenzzeit von weniger als 1 ms befinden, dauern diese 20.000 Transaktionen in der Regel weniger als 20 Sekunden. Die meisten Menschen würden nicht zweimal darüber nachdenken, wenn AutoCAD 20 Sekunden zum Öffnen einer komplexen Datei mit mehreren xrefs benötigt.
Eine Verbindung von Küste zu Küste in Nordamerika beträgt in der Regel 100 ms oder weniger (dies gilt auch für die meisten Kontinente). Man kann sich also leicht vormachen, dass 80 ms Latenzzeit nichts sind. Für den Durchschnittsmenschen ist sie praktisch nicht wahrnehmbar.
Selbst 10 Transaktionen mit 80 ms sind für den Durchschnittsnutzer noch unbedeutend.
Aber wenn Sie 20.000 Transaktionen durchführen müssen und jede dieser Transaktionen einer Latenzzeit unterliegt, warten Sie jetzt insgesamt 1.600 Sekunden auf das Öffnen einer Datei - das sind 26 Minuten und 40 Sekunden!
Wie bat365 die Latenz im Wide Area Network überwindet (wo andere Lösungen versagen)
Der Ansatz vonbat365zur Lösung von Latenzzeiten über das WAN besteht darin, die überwiegende Mehrheit dieser Anrufe lokal auf dem Client-Rechner zu halten. Wenn Sie also Ihr CAD-System auf Ihrem Laptop oder Desktop betreiben, sind Sie mit einem bat365 Filer direkt in Ihrem LAN verbunden.
Jetzt liegt die Latenzzeit für jede dieser 20.000 Transaktionen wieder unter 1 ms, und mit einem SSD-Flash-System liegen die Öffnungszeiten oft unter 10 Sekunden.
Wenn Sie an einer VDI in der Cloud arbeiten, können Sie sich mit einem bat365 Filer direkt daneben in der Cloud verbinden und die gleiche Latenzzeit von unter einer Millisekunde erreichen.
Dateisperrung in Echtzeit ohne Latenz
bat365 erstellt ein globales Dateisystem - CloudFS -, das so viele globale Niederlassungen wie möglich miteinander verbindet und es ihnen ermöglicht, so zu arbeiten, als ob sich alle im selben Büro befänden.
Daher muss CloudFS das Sperren über eine beliebige Anzahl von Standorten hinweg verwalten. Dies führt zu einem gewissen WAN-Verkehr, aber da bat365 das Betriebssystem auf dem Filer ist, kann es den WAN-Verkehr auf ein Minimum beschränken. Der Ansatz von bat365, eine einzige Sperre für jede Datei aufrechtzuerhalten und diese von Filer zu Filer zu verschieben, bedeutet, dass, wenn die Sperre für die zu öffnende Datei bereits auf dem Filer existiert, praktisch kein WAN-Verkehr zum Öffnen der Datei erforderlich ist.
Das bedeutet auch, dass die Dateisperrung in Echtzeit erfolgt und sich genauso verhält, als würde der Benutzer mit einer auf dem lokalen NAS gespeicherten Datei arbeiten und über das lokale Netzwerk darauf zugreifen.
Das Gleiche gilt auch für das Speichern einer Datei. Da fast alle Transaktionen mit einem lokalen Filer über eine Sub-Millisekunden-Verbindung ablaufen, erfolgt das Speichern schnell und effizient.
Das Ergebnis ist eine AutoCAD-Dateileistung, die sich lokal anfühlt, obwohl die Datei selbst in einem zentralisierten Cloud-Speicher von AWS, Microsoft Azure, Google Cloud oder sogar einem privaten Cloud-Anbieter (vor Ort) gespeichert ist.
Was als Lösung für die langsame Netzwerkleistung von AutoCAD begann, war die Geburtsstunde der Remote-Arbeit
Anfang 2020 war ich - zusammen mit dem gesamten Team von bat365 - dabei, einigen der weltweit größten Architektur-, Ingenieur- und Baufirmen bei der Umstellung auf Remote-Arbeit zu helfen, und das in großer Eile.
2020 wird für immer als das Jahr bekannt sein, in dem sich Investitionen in globale Cloud-Dateisystemtechnologie eindeutig auszahlen.
bat365 könnte bereits kritische Dateivorgänge wie Dateisperren und Byte-Range-Sperren in Echtzeit ermöglichen, während ein ganzes Unternehmen mit einem Cloud-basierten Datensatz arbeitet. Als Unternehmen auf der ganzen Welt ihre Mitarbeiter nach Hause schickten, wurde mir klar, dass dies vielleicht das beste Beispiel dafür war, warum die Überwindung von Latenzzeiten im WAN wirklich wichtig ist.
Nun hatten wir nicht nur mit dem WAN zu kämpfen, sondern auch mit persönlichen Internetverbindungen.
Früher installierte bat365 in der Regel Filer (in der Regel virtuelle Maschinen) vor Ort, um häufig verwendete Dateien zwischenzuspeichern und eine niedrige Latenzzeit zu erreichen.
Im Jahr 2020 haben wir diese Filer einfach in Cloud-Regionen platziert - und zwar in den Regionen, die den Unternehmen am nächsten lagen. Diese Installationen mit niedrigen Latenzzeiten halfen vielen der weltweit größten AEC-Firmen bei der Umstellung auf Remote-Arbeit, ohne die Leistung von AutoCAD-Dateien merklich zu beeinträchtigen.
Ich bin besonders stolz auf einige unserer langjährigen AEC-Kunden - Mead & Hunt in Madison, WI, und Garver in North Little Rock, AR, sind zwei großartige Beispiele dafür -, dass sie trotz aller Herausforderungen im Jahr 2020 ihr bisher bestes Jahr erreicht haben. Ebenso haben Firmen wie C&S, Fluor, WSP und Gensler trotz der Notwendigkeit, große globale Belegschaften innerhalb weniger Wochen auf Fernarbeit umzustellen, ihre Leistung konstant gehalten.