Managed Center – APM powered by Tideways

Ihr digitales Sicherheitsnetz: Mit APM powered by Tideways behalten Sie die Antwortzeiten und Fehlerraten Ihres Shops in Echtzeit im Blick. Wichtige Kennzahlen direkt im Managed Center machen Performance-Engpässe sofort sichtbar, sodass Sie proaktiv gegensteuern und Ihren Umsatz jederzeit absichern können.

Der Zugriff auf APM powered by Tideways erfolgt über das Managed Center Ihres Clusters. 

Was ist APM powered by Tideways?

APM (Application Performance Monitoring) ist ein Verfahren zur Überwachung und Analyse der Performance von Anwendungen. Es erfasst Metriken wie Antwortzeiten, Fehlerraten und Durchsatz, um Engpässe in Code, Datenbank, Caching oder Infrastruktur sichtbar zu machen.

Tideways ist ein Profiling- und Application Performance Monitoring (APM)-Tool für PHP-Anwendungen, mit dem Performance, Stabilität und Effizienz überwacht und optimiert werden können. Weitere Informationen über Tideways finden Sie in unserem Blog-Beitrag unter Flaschenhälse erkennen - Tideways.

Mit APM powered by Tideways integrieren wir zentrale Performance-Metriken von Tideways direkt in das Managed Center. 

Damit erhalten Sie:

• Eine “Single Source of Truth”: Alle Beteiligten blicken auf dieselbe, verlässliche Faktenbasis im Kontext Ihres Clusters. Missverständnisse werden vermieden, da Daten nicht mehr mühsam aus verschiedenen Quellen zusammengeführt werden müssen.
• Klarheit statt “Blame Game”: Sie erkennen auf einen Blick, ob Performance-Engpässe aus der Infrastruktur (Server) oder dem Anwendungscode stammen. Diese Transparenz beschleunigt die Fehlersuche und sorgt für eine zielgerichtete Zusammenarbeit zwischen Hoster und Agentur.
• Einen zentralen Einstiegspunkt: Ob Shopbetreiber, Agentur-Mitarbeiter oder maxcluster-Support – alle nutzen dieselbe Oberfläche. Das spart wertvolle Zeit, da der Wechsel zwischen verschiedenen Tools und Logins entfällt.

APM powered by Tideways im Managed Center öffnen

Um APM powered by Tideways im Managed Center zu öffnen, gehen Sie bitte wie folgt vor:

1. Loggen Sie sich zunächst mit Ihren Benutzerdaten unter app.maxcluster.de/login ein. Nach erfolgreicher Anmeldung gelangen Sie automatisch in Ihre Übersicht.
2. Öffnen Sie das Managed Center Ihres Clusters. Sie werden dann in die Dashboard-Ansicht weitergeleitet.
3. Klicken Sie in dem linken Navigationsmenü zuerst auf Analyse und dann auf APM powered by Tideways. Ihnen wird das APM powered by Tideways-Dashboard angezeigt.
4. Nutzen Sie den Domain- und Zeitraum-Filter, um sich gezielt relevante Zeitfenster (z. B. während einer Kampagne oder eines Releases) anzeigen zu lassen.
   • Domain: Nutzen Sie den Domain-Filter, um den virtuellen Host auszuwählen, dessen Performance-Daten Sie betrachten möchten. Es werden alle Domains angezeigt, die in allen Servern des Clusters hinterlegt sind und für die APM-Daten gesammelt werden. 
   • Zeitraum: Wählen Sie das gewünschte Analyse-Intervall, z. B. Letzte Stunde, 24 Stunden, 5 Tage oder 30 Tage aus. Die Anzeige wird entsprechend aktualisiert.
5. Der Hauptgraph ist ein Stacked Area Chart (gestapeltes Flächendiagramm). Das bedeutet, alle Werte (PHP, SQL, Redis etc.) werden übereinandergelegt, um die gesamte Antwortzeit darzustellen.
   
   

Grundkonfiguration für APM powered by Tideways

APM powered by Tideways wird gemäß unserem „Zero-Config“-Ansatz automatisch für nahezu alle Domains aktiviert, sodass keine manuelle Einrichtung pro Shop erforderlich ist. Das Monitoring steht für alle aktiven Domains zur Verfügung; lediglich der „default“-Domain ist von der Erfassung ausgeschlossen. Für die Nutzung ist kein Tideways Lizenz-Key notwendig, da die Einrichtung und Aktivierung vollständig automatisiert erfolgt.

So stellen Sie sicher, dass APM powered by Tideways korrekt für Ihren Shop aktiviert ist:

1. Domain eintragen
   Vergewissern Sie sich, dass die Domains Ihres Shops im Webserver-Bereich korrekt konfiguriert sind, damit APM die Requests dieser Domain zuordnen kann. 
2. Testlast erzeugen
   Rufen Sie die Shop-Startseite sowie typische Shop-Seiten (Kategorie, Produktdetail, Checkout) mit einem Browser oder Last-Tool auf, um einige Minuten lang Traffic zu erzeugen.
3. Daten im APM powered by Tideways-Bereich verifizieren
   Kehren Sie zum APM powered by Tideways-Dashboard zurück und prüfen Sie, ob im gewählten Zeitraum Daten im Stacked Area Chart, in den Gauges und in den Tabellen angezeigt werden.

APM powered by Tideways-Dashboard

Sobald Sie im APM powered by Tideways-Dashboard eine Domain und einen Zeitraum auswählen, aktualisiert sich die Ansicht automatisch. Der Graph visualisiert die Antwortzeit (Response Time) in Millisekunden für den von Ihnen definierten Bereich.

Für Ihre Analyse gelten folgende Zeiträume der Datenhaltung:

• Detail-Analyse (5 Tage): Für eine punktgenaue Fehlersuche stehen Ihnen hochauflösende Daten auf Minutenbasis für die letzten 5 Tage zur Verfügung.
• Trend-Analyse (30 Tage): Um langfristige Entwicklungen zu beobachten, greift das System auf aggregierte Daten (Stundenmittelwerte) für bis zu 30 Tage zurück.

Weitere Informationen im APM powered by Tideways-Dashboard

• Performance-Layer im Stacked Area Chart
  Die Anzeige im Stacked Area Chart ist nach Performance-Layer aufgeteilt für z.B. PHP, SQL, Redis, Externe HTTP-Aufrufe und Autoloading. So erkennen Sie auf einen Blick, welcher Layer für langsame Antwortzeiten verantwortlich ist (z. B. ansteigende SQL-Fläche bei Lastspitzen).

  

• Die interaktive Legende ist mehr als nur eine Erläuterung der Farben in Ihrem Performance-Graphen. Mit ihr können Sie einzelne Performance-Layer gezielt ein- oder ausblenden. So blenden Sie weniger relevante Informationen aus und konzentrieren sich auf die Daten, die Sie aktuell analysieren möchten.
  • Toggle-Funktion: Durch einfaches Klicken auf ein Element in der Legende (z. B. auf "SQL") können Sie diesen Layer im Graphen ein- oder ausblenden. Eine Beschreibung der einzelnen Elemente in der Legende finden Sie weiter unten.
  • Isolations-Modus: Um zu prüfen, ob die SQL-Latenz mit anderen Auffälligkeiten zusammenhängt, können Sie einzelne Performance-Layer gezielt ausblenden. Blenden Sie zum Beispiel PHP aus, wenn dort gerade ein starker Peak vorliegt. Der Graph skaliert sich anschließend automatisch neu, sodass auch kleinere Schwankungen im SQL-Bereich besser sichtbar werden.
  
  

  Abhängig von dem, was auf Ihrem Cluster läuft, können hier folgende Elemente angezeigt werden:

  • Requests: Die durchschnittliche Gesamtantwortzeit aller Requests und damit der Referenzwert, an dem sich die einzelnen Layer-Zeiten orientieren.
  • PHP: Die reine Ausführungszeit des PHP-Codes auf der CPU. Hierzu zählen Logik, Schleifen, Datenverarbeitung und das Zusammensetzen von Variablen.
  • SQL: Die Zeit, die für Datenbankabfragen (z. B. MySQL, PostgreSQL) aufgewendet wird. Dies umfasst sowohl die Ausführungszeit der Queries als auch die Wartezeit auf die Antwort des Datenbankservers nach dem Absenden der Abfrage bzw. die Zeit, die während eines Traces für das Ausführen von SQL-Queries aufgewendet wird.
  • Redis: Die spezifische Zeit für Operationen auf dem Redis-Server, also Key-Value-Zugriffe, Caching-Operationen oder Session-Speicherungen, gemessen als durchschnittliche Dauer pro Request bzw. als Zeit für Redis-Operationen während eines Traces.
  • Externe API (HTTP): Die Dauer von ausgehenden HTTP-Requests an interne oder externe HTTP-APIs. Dazu gehören Netzwerkaufrufe, die über cURL, file_get_contents oder PHP-Streams gestartet werden (z. B. REST-Schnittstellen, Microservices, Zahlungs- oder Tracking-Dienste).
  • Memcache: Die Zeit, die während eines Traces für Memcache-Operationen aufgewendet wird.
  • MongoDB: Die Zeit, die während eines Traces für MongoDB-Operationen aufgewendet wird.
  • Elasticsearch: Die durchschnittliche Zeit, die für Such- und Index-Operationen auf Elasticsearch aufgewendet wird bzw. die Zeit für Elasticsearch-Operationen während eines Traces. Dieser Layer ist insbesondere relevant, wenn der Shop Suchfunktionen oder Produktkataloge über Elasticsearch bereitstellt.
  • File I/O: Die Zeit, die während eines Traces für Dateioperationen wie copy, move, is_dir, fopen, fread und ähnliche Funktionen aufgewendet wird. Es werden nur Operationen gezählt, die über den file://-Stream ausgeführt werden.
  • Session: Die Zeit, die PHP benötigt, um Session-Daten zu lesen oder zu schreiben. Gleichzeitig kann dieser Layer auf versteckte Blocker hinweisen, wenn das Session-Locking bei parallelen Zugriffen greift und Requests dadurch ausgebremst werden.
  • Autoloading: Die Zeit, die der PHP-Autoloader zum Laden von Klassen benötigt bzw. die Zeit, die während eines Traces im Autoloader verbracht wird. Das Autoloaden der notwendigen PHP-Skripte kann einen signifikanten Anteil an der Gesamtlaufzeit ausmachen und somit ein potenzieller Flaschenhals sein. Der Timer umfasst auch die Zeit für das Kompilieren eingebundener Dateien sowie zusätzliche Datei-Operationen, z. B. file_exists()‑Prüfungen.
  • Compiling: Die Zeit, die für das Kompilieren von PHP-Skripten zu Bytecode benötigt wird. Bei aktiviertem OPcache sollte dieser Wert bei 0 ms oder sehr nahe daran liegen, da Skripte in der Regel nur bei Deployments kompiliert werden müssen.
  • APCu: Die Zeit für Operationen auf dem lokalen APCu-In-Memory-Cache, der häufig für schnelle Key-Value-Zugriffe innerhalb eines PHP-Prozesses genutzt wird.
  • Non-CPU Time: Die Zeitspanne innerhalb eines PHP-Requests, in der die CPU keine aktiven Berechnungen durchführt, sondern auf externe Ressourcen wartet (I/O-Wait). Dazu zählen Wartezeiten auf Netzwerk, Festplatte, Datenbank oder externe Dienste.
  • Waiting for CPU: Die Zeit, in der der PHP-Prozess während eines Traces im Warteschlange-Scheduler (Runqueue) des Betriebssystems auf einen freien CPU-Kern wartet, um den Request weiter zu verarbeiten. Wenn der Großteil der Traces hohe Werte für „Waiting for CPU“ aufweist, deutet dies auf unzureichend verfügbare CPU-Ressourcen und eine mögliche Überlastung des Servers hin. Diese Metrik ist in neueren Versionen der Tideways-PHP-Extension verfügbar und löst Teile der zuvor nicht zugeordneten Wartezeit („Unaccounted Wait“) auf.
  • Unaccounted Wait: Die verbleibende Zeit innerhalb eines Traces, die nicht durch die bekannten, oben genannten Layer erklärt werden kann und daher keinem spezifischen Layer eindeutig zugeordnet werden konnte.

• Präzise Analyse per Mouseover: Die „Lupen-Funktion“
  Sobald Sie mit der Maus über den Graphen fahren, aktivieren Sie die Lupen-Funktion für diesen exakten Moment. Ein interaktiver Tooltip schlüsselt Ihnen die Performance-Werte sofort auf:

  • Quantifizierung von Peaks: Sie sehen die genauen Millisekunden-Werte pro Performance-Layer (z. B. “PHP: 150 ms”, “SQL: 400 ms”).
  • Punktgenaue Zuordnung: Ausschläge im Graphen lassen sich sofort bewerten und zeitlich exakt einordnen.
  
• Die Gauges (“Tacho-Anzeigen”) zeigen Ihnen auf einen Blick den aktuellen technischen Zustand Ihres Shops. Während der Performance-Graph die Latenz darstellt, geben die Gauges einen schnellen Überblick darüber, wie sich die Antworten Ihres Webservers verteilen. So erkennen Sie frühzeitig, ob Auffälligkeiten oder Fehler vorliegen.
  
  Die Anzeige fasst die Responses Ihres Webservers in vier Statuscode-Gruppen zusammen. So erkennen Sie auf einen Blick, wie sich Ihre Requests verteilen:
  • Erfolgreich / Success 2xx: Diese Anfragen wurden erfolgreich verarbeitet. Die aufgerufene Seite oder Ressource wurde korrekt ausgeliefert. Dieser Bereich sollte den größten Anteil ausmachen.
  • Weiterleitungen / Redirects 3xx: Diese Anfragen führen zu einer Weiterleitung, zum Beispiel von einer alten URL auf eine neue. Einzelne Redirects sind normal. Eine auffällig hohe Anzahl kann jedoch auf unnötige Umleitungen oder Optimierungsbedarf bei der URL-Struktur hinweisen.
  • Client Fehler / Client Error 4xx: Diese Statuscodes weisen auf Fehler auf der Client-Seite hin, zum Beispiel 404 Not Found. In diesem Fall wurde eine Seite oder Ressource angefragt, die nicht vorhanden ist.
  • Server Fehler / Server Error 5xx: Diese Statuscodes deuten auf Probleme auf Server-Seite hin, zum Beispiel 500 Internal Server Error. Tritt dieser Bereich vermehrt auf, sollten Sie die Ursache zeitnah prüfen, da betroffene Seiten für Besucherinnen und Besucher nicht korrekt ausgeliefert werden.
  

Die Tabellen unterstützen Sie bei der Analyse von Performance-Problemen im Detail. Während der Graph sichtbar macht, dass eine Auffälligkeit vorliegt, zeigen Ihnen die Tabellen, welche Endpunkte oder Abläufe dafür verantwortlich sind. So erhalten Sie konkrete Ansatzpunkte für die weitere Analyse und Optimierung.

• Die Transactions Tabelle zeigt Ihnen alle aufgerufenen Endpunkte Ihres Shops, zum Beispiel die Startseite, Produktdetails oder den Warenkorb.

Was die Tabelle zeigt: Die Endpunkte werden nach Last oder Latenz sortiert. So sehen Sie, welche Bereiche besonders häufig aufgerufen werden oder auffällig langsam reagieren.

Ihr Nutzen: Sie erkennen schnell, ob ein Performance-Problem den gesamten Shop betrifft oder nur einen bestimmten Bereich.

Beispiel: Wenn ausschließlich der Endpunkt /checkout/finish auffällig langsam ist, liegt die Ursache eher im Checkout-Prozess, beim Payment-Provider oder beim Versand der Bestätigungs-E-Mail als beim Server selbst.

Wichtig für die Analyse: Achten Sie nicht nur auf die Dauer einzelner Requests, sondern auch auf deren Häufigkeit. Ein Endpunkt mit 500 ms Antwortzeit und 10.000 Aufrufen pro Stunde kann einen größeren Einfluss haben als ein Endpunkt mit 2 Sekunden Antwortzeit, der nur einmal pro Tag aufgerufen wird.

• Die Slow SQL Queries Tabelle hilft Ihnen dabei, langsame Datenbankabfragen gezielt zu identifizieren. Da SQL-Abfragen häufig eine wesentliche Ursache für Performance-Probleme sind, ist diese Tabelle besonders hilfreich für die technische Analyse.

Was die Tabelle zeigt: Sie listet die langsamsten SQL-Abfragen auf, die im ausgewählten Zeitraum ausgeführt wurden.

Besonders hilfreich:  Zu jeder langsamen Abfrage stellt das APM powered by Tideways zusätzliche Informationen zur Verfügung, darunter auch einen Stacktrace. So sehen Sie, an welcher Stelle im Code die Abfrage ausgelöst wurde, zum Beispiel im Shopware-Core, in einem Plugin oder in einem Magento-Modul.

Ihr Nutzen: Statt die Ursache aufwändig suchen zu müssen, erhalten Ihre Entwickler konkrete Hinweise auf die betroffene Datei und Code-Stelle. Das erleichtert die Analyse und beschleunigt die Optimierung.

Mit einem Klick auf den jeweiligen Eintrag (Auge) erhalten Sie weitere Detailinformationen.

• Die Tabelle External Services zeigt Ihnen, welchen Einfluss externe Dienste auf die Performance Ihres Shops haben. Moderne Shops sind häufig an verschiedene Drittanbieter angebunden, zum Beispiel Zahlungsdienste, Tracking-Lösungen oder externe Schnittstellen. Reagieren diese Dienste langsam, wirkt sich das auch auf die Lade- und Antwortzeiten Ihres Shops aus.

Was die Tabelle zeigt: Sie listet alle ausgehenden HTTP-Aufrufe auf, die Ihr Server an externe Dienste sendet.

Ihr Nutzen: Sie erkennen, ob Performance-Probleme durch externe Abhängigkeiten verursacht werden und nicht durch Ihren Shop oder Server selbst.

Beispiel: Wenn sich Ihre Kunden über einen langsamen Checkout beschweren, können Sie in dieser Tabelle prüfen, ob ein angebundener Zahlungsdienst auffällig langsam antwortet.

Einordnung: Zeigt die Tabelle beispielsweise, dass eine externe API statt wie üblich in 100 ms erst nach 2.000 ms antwortet, spricht das für eine Verzögerung beim jeweiligen Drittanbieter. So lässt sich die Ursache eines Performance-Problems gezielter eingrenzen.

Troubleshooting

1. Es werden keine Daten im APM powered by Tideways-Dashboard angezeigt
   • Prüfen Sie, ob Sie die korrekte Domain und einen Zeitraum mit Last ausgewählt haben.
   • Zum Testen erzeugen Sie Test-Requests auf dem Shop (Startseite, Produktseite, Checkout) und aktualisieren Sie das Dashboard.
2. Der Tacho-Anzeige „Server Fehler“ zeigt Fehler, aber keine klaren Hinweise auf die Ursache
   • Klicken Sie auf „Server Fehler“, um die zugehörige Fehler- oder Transaktionsliste zu öffnen.
   • Prüfen Sie, ob bestimmte Endpunkte oder externe APIs gehäuft betroffen sind.
   • Vergleichen Sie den Zeitpunkt des Fehlers mit dem Zeitpunkt im Graphen auf dem APM powered by Tideways-Dashboard, um weitere Anhaltspunkte für den Fehler zu erhalten.
3. Hohe Latenzen in SQL, aber unklare Ursache im Code
   • Öffnen Sie das SQL Queries Log und analysieren Sie die langsamsten Queries.
   • Nutzen Sie den Stacktrace, um die Quelle im Shop-Code (z. B. Modul oder Plugin) zu identifizieren.
   • Leiten Sie diese Informationen an Ihre Entwickler oder Agentur weiter.
4. Redis-Latenz auffällig hoch
   • Prüfen Sie in der Layer-Darstellung, ob Redis über einen längeren Zeitraum dominante Latenzen aufweist.
   • Validieren Sie die Redis-Konfiguration und Auslastung im Monitoring Center.
   • Kontaktieren Sie bei anhaltenden Auffälligkeiten den maxcluster-Support, um Infrastruktur-Optimierungen vorzunehmen.
5. Externe APIs verlangsamen den Shop
   • Nutzen Sie das External Services (API Monitoring) Log, um langsame oder fehlerhafte externe Services zu identifizieren.
   • Prüfen Sie, ob diese Services zwingend synchron im Request benötigt werden oder ob Caching / Asynchronisierung möglich ist.
   • Ziehen Sie in Erwägung, harte Timeouts zu setzen oder Alternativdienste zu evaluieren.

FAQ

• Ersetzt APM powered by Tideways eine Tideways-Installation?
  Nein. Es bietet eine integrierte, komprimierte Übersicht im Managed Center. Für vollständige Traces, Callgraphs und alle Tideways-Funktionen nutzen Sie Tideways.
  
  
• Wer sollte APM powered by Tideways nutzen?
  APM powered by Tideways unterstützt alle Beteiligten, die an der Stabilität, Performance und Weiterentwicklung eines Onlineshops arbeiten, und fungiert dabei als „Single Source of Truth“. Es schafft eine gemeinsame Datenbasis und erleichtert, technische Auffälligkeiten fundiert zu bewerten und gezielt einzugrenzen.
  • Für Shopbetreiber sowie E-Commerce-Manager: APM powered by Tideways bietet einen schnellen Überblick über den technischen Zustand Ihres Shops. Mithilfe der Gauges erkennen Sie sofort, ob Ihr Shop stabil läuft oder ob technische Fehler vorliegen, die sich zum Beispiel auf den Checkout auswirken. So können Sie Performance-Probleme frühzeitig erkennen und Maßnahmen gezielter priorisieren.
  • Für Web-Agenturen: Das Tool unterstützt Sie dabei, Optimierungen nachvollziehbar zu bewerten und gegenüber Kunden transparent darzustellen. Vorher-Nachher-Vergleiche helfen, die Auswirkungen von Anpassungen sichtbar zu machen. Weiterhin eignet sich APM powered by Tideways als fester Bestandteil der Qualitätskontrolle nach Deployments, um Veränderungen im Verhalten des Shops früh zu erkennen.
  • Für Entwickler und DevOps-Teams: APM powered by Tideways erleichtert die technische Analyse von Performance-Problemen erheblich. Detaillierte Transaction-Listen und Slow SQL Queries mit zusätzlichen Informationen wie Stacktraces helfen dabei, betroffene Code-Bereiche schneller zu identifizieren. So lassen sich Ursachen gezielter analysieren und Optimierungen effizienter umsetzen.
  • Für den maxcluster-Support: Auch im Support erleichtert die gemeinsame Datengrundlage die Zusammenarbeit. Da alle Beteiligten auf dieselben Messwerte und Auswertungen zugreifen, lassen sich Ursachen schneller eingrenzen. So wird klarer, ob ein Problem in der Infrastruktur, im Anwendungscode oder bei einem externen Dienst liegt.