Git wird fit: Mit dem blackfire-Profiler machen wir unsere Projekt-API schneller

Upsun verfügt über eine einzigartige Architektur. Einer der interessantesten Aspekte dieser Architektur ist, dass zwar einige unserer APIs mandantenfähig sind, unsere wichtigste API – diejenige, die jedes Projekt und dessen Umgebungen steuert – jedoch eigentlich ein Single-Tenant-Daemon ist.

Noch interessanter ist, dass dieser Single-Tenant-Daemon eine Multi-Protokoll-API ist, in der die Haupt-API Git spricht. Er stellt außerdem eine REST-API bereit, die wiederum alle seine Git-Funktionen offenlegt und diese um weitere Funktionen ergänzt, wie zum Beispiel die Beantwortung des Befehls zum Zuordnen eines Domainnamens zu einer Umgebung, das Konfigurieren von Zugriffsberechtigungen oder das Skalieren eines Containers in einer Preview-Umgebung. Im Wesentlichen erfolgt jede Änderung an einem laufenden Cluster über den benutzerdefinierten Daemon.

Was ist so gut an einem Single-Tenant-Daemon?

Wenn wir von Single-Tenant sprechen, meinen wir, dass jedes Upsun-Kundenprojekt seinen eigenen, vollständig isolierten Daemon hat. Jeder verfügt über einen eigenen Datenspeicher, der absolut alles enthält, was das Projekt zum Laufen benötigt – alles an einem Ort.

Das bietet unseren Nutzern eine ganze Reihe von Vorteilen. Dazu gehören die extreme Reduzierung von Fehlerzonen, die Möglichkeit, Projekte zwischen Regionen zu verschieben, und die kontinuierliche Bereitstellung neuer Features. Und das alles ohne Risiko, denn dank dieser Architektur kann ein Performance-Problem in einem Projekt kein anderes beeinträchtigen. Und noch besser: Git befindet sich nicht im Anforderungspfad einer laufenden Anwendung; das heißt, es könnte ausfallen, und die konfigurierten Cluster laufen trotzdem problemlos weiter.

Wie lässt sich die Performance bei Single-Tenant-Apps überwachen?

Wir haben viel Gutes über Single-Tenant-Anwendungen gesagt, aber es gibt einige Schwierigkeiten zu beachten, insbesondere was die Beobachtbarkeit und Optimierung der Performance angeht. Schließlich verhält sich ein Projekt mit Hunderten von Branches und einer langen Historie ganz anders als ein Projekt mit einem einzigen Commit. Wenn du also keine Methode festlegst, um die Arbeit an der Performance-Optimierung zu priorisieren, kann es leicht passieren, dass diese wichtige, aber nicht unbedingt kritische Komponente auf der Strecke bleibt und die Performance deiner Anwendung nach und nach immer langsamer wird. Alle Produktionsanwendungen benötigen Observability, und je komplexer Systeme werden, desto größer wird der Bedarf an Einblicken in die Performance.

Während viele Entwickler Observability lediglich als Traces, Logs oder Metriken betrachten, liegt ihr Kern darin, das System abzufragen und potenzielle Engpässe oder Optimierungsbereiche genauer zu untersuchen. Bedenke Folgendes: Ein Entwickler sollte nahtlos von der Frage „Welche Endpunkte hinken hinterher?“ zu der Abfrage übergehen: „Was passiert im Programm während der langsamsten 1 % der HTTP-Anfragen, oder was ist das Besondere an diesen langsamsten Instanzen, Endpunkten oder sogar Benutzern?“ Echte Observability bietet sowohl Tiefe als auch Breite – besonders bei der Verwendung eines leistungsstarken Observability-Tools wie blackfire

Lerne blackfire kennen, den Experten für Monitoring und Profiling

Blackfire unterstützt sowohl Anwendungsüberwachung als auch Profiling, um Einblicke in die Performance und die Optimierung zu maximieren. Überwachung bezieht sich auf einen Überblick über Systemmetriken: HTTP-Status, Anforderungsverzögerungen (P50 und P99), Top-Transaktionen, Antwortzeiten und Speichermetriken, alles organisiert nach HTTP-Attributen und Zeit. Beim blackfire-Profiling hingegen dreht sich alles um die bedarfsgesteuerte Anwendungsanalyse. Um das Profiling zu aktivieren, brauchst du lediglich einen bestimmten HTTP-Header oder eine manuelle Code-Instrumentierung. Und da blackfire als leistungsstarkes Profiling-Tool entwickelt wurde, zeichnet es sich durch die Visualisierung von Daten aus – schau dir das hier an:

Oben siehst du eine traditionelle Callgraph-Visualisierung, die alle Aufrufer-Aufgeforderter-Beziehungen grafisch darstellt. Die Zeitleiste hingegen zeigt die Funktionsaufrufe, die während des Profiling auf einer Zeitachse stattfanden.

Wie du siehst, präsentiert blackfire Wall-Time, CPU-Auslastung und Speicherverbrauch in einem einzigen Profil. So kannst du die Wall-Time, CPU-Zeit und den Speicherverbrauch einer Funktion – in bestimmten Sprachen sogar Netzwerkdaten – in einer einzigen Profiling-Sitzung einsehen. Dank seines deterministischen Profilers – der Messungen durchführt, wenn ein bestimmtes Ereignis wie ein Funktionsaufruf, ein Funktionsausstieg oder eine Ausnahme auftritt – entsteht zwar ein gewisser Overhead, dennoch bietet blackfire eine beispiellose Profiling-Tiefe. Erfahre mehr über die Profiling-Features von Upsun und blackfire.

Die gleichzeitige Nutzung von blackfire-Überwachung und -Profiling bietet dir kontinuierlich die Möglichkeit, Engpässe zu identifizieren und zu beheben. Die Überwachung hebt die Systembereiche mit den größten Zeitverzögerungen hervor, während das Profiling es uns ermöglicht, tief in diese aufkommenden, noch unerforschten Engpässe einzutauchen – eine leistungsstarke Kombination für überragende performance.

Dogfooding und die Implementierung des Git-Dienstes

Wir nehmen Dogfooding sehr ernst. Indem wir unsere eigenen Tools nutzen, erkennen wir Probleme, bevor sie unsere Nutzer erreichen, und verbessern unsere Angebote kontinuierlich. Die Möglichkeit zum Selbsttest ist ein einzigartiger Vorteil für Observability-Tools, und bei Upsun setzen wir voll darauf – es ist ein positiver Kreislauf. So testen wir beispielsweise konsequent jeden Dienst, den wir anbieten, unabhängig von seiner Größe.

Git bildet das Herzstück der Benutzerinteraktionen bei Upsun. Ob bei der Einrichtung der Umgebung oder der Code-Bereitstellung – Git, das auf dem Python-Framework Pyramid aufbaut, spielt eine entscheidende Rolle in unserem Workflow. Und angesichts der Python-Fähigkeiten von blackfire war die Kopplung mit Git eine naheliegende Entscheidung.

Unsere interne Git-Gruppe hat eine WSGI-Middleware für die nahtlose Interaktion mit blackfire entwickelt. Ab Version 1.17.0 unterstützt blackfire Pyramid nativ, was die Integration optimiert. Aber wie genau integrierst du blackfire mit Git? Alles beginnt mit diesem Befehl:

blackfire-python gunicorn --workers=2 test:app

Dieser Befehl sorgt für eine nahtlose Integration mit unterstützten Frameworks – stelle einfach sicher, dass du über eine gültige blackfire-Umgebung und die richtigen Anmeldedaten verfügst. Sobald du die interne Umgebung unseres Git-Dienstes konfiguriert und die Überwachung aktiviert hast, wird unser Dashboard wie folgt angezeigt:

Wenn man sich den obigen Daten-Snapshot ansieht, wird deutlich, dass die Mehrheit unserer Git-Befehle bei etwa 50 ms liegt, was ein gutes Zeichen ist. Dennoch können wir unsere Aufmerksamkeit auf die vier Anfragen richten, die 1,6 s überschreiten, da sie die langsamsten Transaktionen unseres Systems darstellen. Ein Paradebeispiel dafür, wie blackfire-Observability Bereiche mit Optimierungspotenzial aufzeigen kann – doch die Lösung für diesen speziellen Optimierungsbefund ist nicht das Thema des heutigen Beitrags.

Performance-Optimierung in der Praxis

Unsere interne Git-Gruppe hat mehrere Probleme der Performance identifiziert, die ausschließlich in bestimmten Umgebungen auftraten. Die genaue Beschaffenheit dieser Umgebungen blieb unbekannt, was eine lokale Reproduktion erschwerte. Hier 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 anschließend mit blackfire. Unten siehst du einen Screenshot des Profiling eines langsamen Git-Endpunkts:

Ein kurzer Blick auf die wichtigsten Metriken zeigt, dass Wall-Time und CPU-Zeit gleich sind, was auf einen CPU-intensiven Prozess innerhalb der Anwendung hindeutet. Wäre der Engpass hingegen I/O-basiert, wie etwa ein verzögerter Microservice-Aufruf oder ein umfangreicher Dateilesevorgang, würde die Wall-Time die I/O-Zeit widerspiegeln.

Bei genauerer Betrachtung identifiziert die Callgraph-Visualisierung von blackfire Performance-Engpässe, indem sie die zeitaufwändigste Aufrufkette rot hervorhebt und so den kritischen Pfad anzeigt. Dieser Pfad zeigt Funktionen auf, die reif für eine Optimierung sind. 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 ca. 40 % schnelleren Ausführungszeit.

Mit dieser Optimierung zeigt der Callgraph keinen kritischen Pfad mehr an, was bedeutet, dass keine offensichtlichen Bereiche für sofortige Verbesserungen der Performance vorhanden sind. Mit anderen Worten: Weitere Optimierungen sind zwar möglich, aber der Ertrag könnte geringer ausfallen.

Zusammenfassung zum Blackfire-Profiling

Blackfire ermöglicht es uns, uns ganz einfach auf Optimierungen zu konzentrieren, die leicht zu erreichen sind, aber das muss noch nicht alles sein. Mit integrierter Profiling- und Überwachungsfunktion kannst du verschiedene Engpässe in der Produktivumgebung identifizieren und diese nur dann beheben, wenn die Korrekturen einfach zu implementieren und kosteneffizient sind.

Du wirst vielleicht erstaunt sein, welche Möglichkeiten dir mit einem Tool wie blackfire entgehen, insbesondere bei älterem Produktionscode, der zuvor keine Überwachungsfunktionen hatte. Erfahre mehr über unsere Observability-Features oder starte noch heute eine kostenlose Testversion.