Upsun hat eine einzigartige Architektur. Einer der interessantesten Aspekte dieser Architektur ist, dass einige unserer APIs zwar mandantenfähig sind, aber unsere wichtigste API - diejenige, die jedes Projekt und seine Umgebungen steuert - eigentlich ein mandantenfähiger Daemon ist.
Noch interessanter ist, dass dieser mandantenfähige Daemon eine Multiprotokoll-API ist, in der die Haupt-API Git spricht. Er stellt auch eine REST-API zur Verfügung, die wiederum alle Git-Funktionen zur Verfügung stellt und diese um einige weitere ergänzt, wie z. B. die Beantwortung des Befehls zum Zuordnen eines Domänennamens zu einer Umgebung, die Konfiguration von Zugriffsberechtigungen oder das Hochskalieren eines Containers in einer Vorschauumgebung. Im Grunde genommen erfolgt jede Änderung an einem laufenden Cluster über den benutzerdefinierten Daemon.
Wenn wir von Single-Tenant sprechen, meinen wir, dass jedes Upsun-Kundenprojekt seinen eigenen, vollständig isolierten Daemon hat. Jeder hat seinen eigenen Datenspeicher, der alles enthält, was das Projekt zum Laufen braucht - alles an einem Ort.
Dies bietet eine ganze Reihe von Vorteilen für unsere Benutzer. Dazu gehören die extreme Reduzierung von Fehlerzonen, die Möglichkeit, Projekte zwischen Regionen zu verschieben, und die kontinuierliche Bereitstellung neuer Funktionen. Und das alles ohne Risiko, denn ein Leistungsproblem in einem Projekt kann sich dank dieser Architektur nicht auf ein anderes auswirken. Und was noch besser ist: Git befindet sich nicht im Anforderungspfad einer laufenden Anwendung, d. h. diese könnte ausfallen und die konfigurierten Cluster würden problemlos weiterlaufen.
Wir haben viel Gutes über Single-Tenant-Anwendungen gesagt, aber es gibt auch einige Schwierigkeiten zu beachten, insbesondere in Bezug auf die Leistungsüberwachung und -optimierung. Schließlich verhält sich ein Projekt mit Hunderten von Zweigen und einer langen Historie ganz anders als ein Projekt mit einem einzigen Commit. Wenn Sie also keine Prioritäten für die Leistungsoptimierung festlegen, kann es leicht passieren, dass diese wichtige, aber nicht unbedingt kritische Komponente auf der Strecke bleibt und die Leistung Ihrer Anwendung allmählich langsamer und langsamer wird. Alle Produktionsanwendungen benötigen eine Beobachtungsmöglichkeit, und je komplexer die Systeme werden, desto größer ist der Bedarf an Leistungseinblicken.
Viele Entwickler sehen in der Beobachtbarkeit lediglich Traces, Protokolle oder Metriken. Der Kern der Beobachtbarkeit liegt jedoch in der Abfrage des Systems und der tieferen Erforschung potenzieller Engpässe oder optimierungsbedürftiger Bereiche. Ein Ingenieur sollte nahtlos von der Frage "Welche Endpunkte hinken?" zur Frage "Was passiert im Code während der langsamsten 1 % der HTTP-Anfragen, oder was ist einzigartig an diesen langsamsten Instanzen, Endpunkten oder sogar Benutzern?" übergehen. Echte Beobachtbarkeit bietet sowohl Tiefe als auch Breite - vor allem, wenn ein leistungsstarkes Beobachtungstool wie Blackfire verwendet wird.
Blackfire unterstützt sowohl die Überwachung von Anwendungen als auch die Erstellung von Profilen, um die Leistungseinsicht und -optimierung zu maximieren. Monitoring bezieht sich auf einen Überblick über die Systemmetriken: HTTP-Status, Anfrageverzögerungen (P50 und P99), Top-Transaktionen, Antwortzeiten und Speichermetriken, die alle nach HTTP-Attributen und Zeit geordnet sind. Beim Blackfire Profiling hingegen geht es um die Analyse von Anwendungen nach Bedarf. Um das Profiling zu aktivieren, benötigen Sie lediglich einen bestimmten HTTP-Header oder eine manuelle Code-Instrumentierung. Da Blackfire als leistungsfähiges Profiling-Tool entwickelt wurde, eignet es sich hervorragend zur Visualisierung von Daten, wie hier zu sehen ist:
Oben ist eine traditionelle Callgraph-Visualisierung zu sehen, die die grafische Darstellung aller Caller-Callee-Beziehungen zeigt. Die Zeitleiste hingegen zeigt die Funktionsaufrufe, die während der Profilerstellung erfolgten, auf einer Zeitachse.
Wie Sie sehen können, stellt Blackfire Wand/Zeit, CPU-Nutzung und Speicher in einem einzigen Profil dar. So können Sie die Wall/CPU-Zeit und die Speichernutzung einer Funktion - in bestimmten Sprachen sogar Netzwerkdaten - in einer einzigen Profiler-Sitzung sehen. Dank seines deterministischen Profilers - derMessungen vornimmt, wenn ein bestimmtes Ereignis wie ein Funktionsaufruf, ein Funktionsabbruch oder eine Ausnahme eintritt - gibt es zwar einen gewissen Overhead, aber dennoch bietet Blackfire eine unvergleichliche Profiltiefe. Erfahren Sie mehr über die Profiling-Funktionen von Upsun und Blackfire.
Die gleichzeitige Verwendung von Blackfire Monitoring und Profiling bietet kontinuierliche Möglichkeiten, Engpässe zu identifizieren und zu beheben. Die Überwachung hebt die Systembereiche mit den meisten Zeitverzögerungen hervor, während die Profilerstellung es uns ermöglicht, tief in die aufkommenden, noch zu erforschenden Engpässe einzudringen, was eine leistungsstarke Mischung für eine bessere Leistung darstellt.
Wir nehmen Dogfooding sehr ernst. Durch den Einsatz unserer eigenen Tools können wir Probleme erkennen, bevor sie unsere Nutzer erreichen, und unser Angebot kontinuierlich verbessern. Die Möglichkeit, sich selbst zu testen, ist ein einzigartiger Vorteil von Observability-Tools, und bei Upsun machen wir uns das voll zunutze - es ist ein vorteilhafter Kreislauf. So testen wir beispielsweise konsequent jeden von uns angebotenen Service, unabhängig von seiner Größe.
Git ist das Herzstück der Benutzerinteraktionen bei Upsun. Ob es um die Einrichtung der Umgebung oder die Bereitstellung von Code geht, Git, das auf dem Python-Framework Pyramid aufbaut, spielt eine entscheidende Rolle in unserem Workflow. Und angesichts der Python-Fähigkeiten von Blackfire war es eine intuitive Entscheidung, es mit Git zu verbinden.
Unsere interne Git-Gruppe hat eine WSGI-Middleware für die nahtlose Interaktion mit Blackfire entwickelt. Seit der Version 1.17.0 unterstützt Blackfire nativ Pyramid, was die Integration vereinfacht. Aber wie genau integriert man Blackfire mit Git? Es beginnt alles mit diesem Befehl:
blackfire-python gunicorn --workers=2 test:app
Dieser Befehl stellt eine nahtlose Integration mit unterstützten Frameworks sicher. Stellen Sie einfach sicher, dass Sie mit einer gültigen Blackfire-Umgebung und den richtigen Anmeldedaten ausgestattet sind. Sobald Sie die interne Umgebung unseres Git-Dienstes konfiguriert und die Überwachung aktiviert haben, wird unser Dashboard wie folgt angezeigt:
Aus dem obigen Daten-Snapshot ist ersichtlich, dass sich die meisten unserer Git-Befehle im Bereich von 50 ms bewegen, was ein gutes Zeichen ist. Dennoch können wir unsere Aufmerksamkeit auf die vier Anfragen richten, die 1,6 Sekunden überschreiten, da sie die langsamsten Transaktionen unseres Systems darstellen. Ein Paradebeispiel dafür, wie die Beobachtbarkeit von Blackfire Bereiche für Optimierungen aufzeigen kann - aber die Lösung für diese spezielle Optimierungsaufgabe ist nicht das Thema für heute.
Unsere interne Git-Gruppe ermittelte mehrere Leistungsprobleme, die nur in bestimmten Umgebungen auftraten. Die genaue Beschaffenheit dieser Umgebungen blieb unbekannt, was die lokale Reproduktion zu einer Herausforderung machte. An dieser Stelle erwies sich das On-Demand-Profiling von Blackfire als unschätzbar wertvoll. Das Team erstellte Profile für bestimmte HTTP-Anfragen und analysierte die Ergebnisse mit Blackfire. Unten sehen Sie einen Screenshot der Profilerstellung eines langsamen Git-Endpunkts:
Ein kurzer Blick auf die wichtigsten Metriken zeigt, dass die Wandzeit und die CPU-Zeit gleich sind, was auf einen CPU-intensiven Prozess innerhalb der Anwendung hindeutet. Wäre der Engpass hingegen I/O-basiert, wie z.B. ein verzögerter Microservice-Aufruf oder ein umfangreicher Dateilesevorgang, würde die Wandzeit die I/O-Zeit widerspiegeln.
Wenn man tiefer eintaucht, identifiziert Blackfires Callgraph-Visualisierung Leistungsbremsen, indem sie die zeitaufwändigste Aufrufkette rot hervorhebt und so den kritischen Pfad anzeigt. Dieser Pfad zeigt Funktionen an, die optimiert werden sollten. Die Analyse des Git-Teams deckte eine redundante Funktion in diesem kritischen Pfad auf, die ein großes Array verarbeitete und unnötige Isinstance-Prüfungen durchführte. Die Beseitigung dieser redundanten Funktion führte zu einer um 40 % schnelleren Ausführungszeit.
Nach dieser Optimierung zeigt der Callgraph keinen kritischen Pfad mehr an, was bedeutet, dass keine offensichtlichen Bereiche für unmittelbare Leistungsverbesserungen verbleiben. Mit anderen Worten bedeutet dies, dass weitere Optimierungen möglich sind, aber die Erträge könnten weniger fruchtbar sein.
Blackfire ermöglicht es uns, uns auf die niedrig hängenden Früchte der Optimierung zu konzentrieren, aber dabei muss es nicht bleiben. Mit integriertem Profiling und Monitoring können Sie verschiedene Engpässe in Produktionssystemen identifizieren und diese nur dann beheben, wenn die Korrekturen einfach zu implementieren und kosteneffizient sind.
Sie werden erstaunt sein, welche Möglichkeiten Ihnen mit einem Tool wie Blackfire entgehen, insbesondere bei Legacy-Produktionscode, für den es bisher keine Überwachungsfunktionen gab. Erfahren Sie mehr über unsere Observability-Funktionen oder starten Sie noch heute eine kostenlose Testversion.