APM für Shopware | Tideways, New Relic und Datadog

APM – steht für „Application performance management“ und ist ein wichtiger Bestandteil einer erfolgreichen Ecommerce Unternehmung. Denn neben einer top UX und schickem Design hat die Geschwindigkeit einen direkten Einfluss auf die Conversionrate.

Die drei Kanidaten

Ich weiß das es noch einige andere APM Anbieter gibt, ich habe mich aber für diese 3 entschieden, da ich auch produktiv mit Ihnen gearbeitet habe.

 

Preise

Fangen wir beim günstigsten und wie ich finde auch transparentesten an, Tideways:

„Pretty straight forward“ – Ihr könnt den Service für 14 Tage voll testen. Das würde ich euch auch auf jeden Fall empfehlen.

Datadog ist ähnlich simpel aufgestellt, aber gerade bei vielen Hosts wird das ganze etwas teuer:

 

 

 

 

New Relic ist der undurchsichtigste Anbieter im Vergleich – anbei findet Ihr eine Kalkulation für einen AWS Server bei 750h Nutzung:

 

Vielen nutzen allerdings keine AWS oder andere Cloudserver, sondern sind bei versch. Hostern untergebracht (Hosteurope, Timmer Hosting etc. pp.)

Die Preis berechnen sich dabei wie folgt -> 1 GB / 1 CPU-Kern sind jeweils ein CU. Bei unseren Servern mit 12GB Ram und 4 Cores ist das dann 16 als Faktor.

16 x 720h (1 Monat) = 11520 CU -> ca. 200USD

Das ist nicht wirklich transparent und gerade wenn man hin und wieder Server wechselt oder skaliert ist das ein Buchhaltungschaos.

New Relic ist laut einem SalesRep scheinbar kulant was kurzzeitige Spitzen angeht. Ich empfand den Prozess der Berechnung aber als sehr kompliziert und aufwendig.

Möchte man fixe Preise zahlen (wenn man einen Managed Server hat z.B. und keine Cloud Server) – dann sind es 149$ für die Pro Version und 75$ für die Essentials Version – pro Host/Server.

 

 

Skalierung/Kosten

Fangen wir mal wieder bei Tideways an – Ihr könnt hier so viele Hosts wie Ihr möchtet implementieren (Host = Domain). In der vorgestellten Standard Variante könnt Ihr außerdem bis zu 10 Server einbinden.

Datadog und New Relic berechnen hier nach Server – wovon ich ehrlich gesagt kein Fan bin. Ich würde es verstehen wenn Sie nach Transaktionen berechnen würden, so kann man auch mal 1-2 Server aus der Loadbalancer Verteilung nehmen ohne weiterhin 50-150$ zu zahlen. Man kann hier sicher teilweise etwas aushandeln, das kostet aber natürlich wieder Arbeitszeit und die ist in den meisten Fällen wertvoller.

Was die Skalierung an sich angeht, dies ist bei allen Anbietern ohne Probleme möglich. Einfach den Daemon auf dem jeweiligen Server starten, konfigurieren und 1 min später sieht man die ersten Transactions (oder auch nicht…).

 

Datadog und PHP

Bevor wir hier weiter machen und über Funktionen und Transaktionen sprechen muss ich noch kurz einwerfen das Datadog aktuell kein PHP unterstützt.

Laut Website geht aktuell von Haus aus nur Python, Ruby, Go und Java. „Warum hast du es dann in den Vergleich genommen, Micha?“ Weil unser Hoster dies in Kürze als Service anbietet und ich vermute das die PHP Unterstützung in Kürze kommt. Es gibt scheinbar auch Wege über Github Repos diese Funktion zu nutzen. Darauf gehe ich aber in einem anderen Artikel ein.

Sie haben aber wohl schon einmal gemerkt das die Nachfrage da ist:

Hoffe wir mal das Sie in Kürze nachziehen und Ihr APM auch PHP unterstützt.

Transactions

New Relic

Der wichtigste Teil der APMs sind die Transaktionen. Diese informieren über Details eines Aufrufes, wie zum Beispiel das in den Warenkorb legen oder den Login Prozess.

In New Relic sieht das ganze dann so aus:

Wichtig hierbei ist das Ihr ein Plugin in Shopware installiert, welches euch die Transactions entsprechend übersetzt. Sonst steht statt Kategorielisting dann frontend/listing/index dort. Nicht zwingend notwendig, aber es wirkt etwas sauberer und so können auch andere Abteilungen schnell verstehen um was es geht (ohne die Struktur von Shopware Controllern und Actions zu kennen)

Transactions werden in New Relic nur bei Slow Requests gespeichert und auch sichtbar. Setzt man den Apdex Wert also zu hoch – werden keine Transactions in New Relic APM ausgegeben. Leider hat mir der SalesRep von New Relic einen Wert von 1.3 empfohlen, was bedeutet das kein Request unter 5.2 Sekunden überhaupt aufgezeichnet wird. Das sind natürlich nur die wirklich kritischen – wollte Ihr hier mehr sehen, setzt den Wert auf 0.4 oder 0.5 (unter Application -> Settings in der linken Sidebar)

Wählt man einen Trace aus – sieht das wie folgt aus:

 

 

In Trace Details findet man dann die einzelnen Funktionsaufrufe und Queries – das durchklicken kann hier schon etwas dauern und ist etwas müßig. Über Expand Performance Problems geht das aber mit nur einem Klick.

Über das Datenbank Icon kommt man dann auch zur detaillierten Queryansicht und wenn es sich um ein Slow Query handelt bekommt man auch Empfehlungen warum es langsam ist (temp tables etc.)

Overall muss ich sagen ist das Handling im Backend relativ träge und das nur 4 Transactions angezeigt werden ist eigentlich nicht akzeptabel. Hier würde ich mir mindestens 10-20 Wünschen.

Tidways

Tideways ist hier schon einen Schritt weiter – hier werden die meisten Transactions bereit übersetzt bzw. zugeordnet

Account Login oder Product | Details lassen direkt erkennen um was es geht und man kann Sie bei Bedarf auch umbenennen:

Nett wäre hier noch eine Suche, denn wenn man erstmal produktiv fährt stehen hier + 200 Transactions

Die Navigation zwischen einzelnen Traces ist wesentlich performanter und deren Anzeige/Analyse ist je nach Version bis zu 14 Tage möglich

 

 

Öffnet man den Trace im Detail sieht man folgendes:

Das ganze ist etwas aufgeräumter und unter Bottlenecks findet Ihr gleich ein paar Anhaltepunkte für Optimierungen. In unserem Fall schauen wir uns aber mal Calls an, in diesem ist ein fget ein enormer Zeitfresser

3 Sekunden ist natürlich schon ein echter Blocker – woher das ganze kommt sehen wir beim Klick auf den Callgraph

Wow! 51 Calls der fgets Funktion (http://php.net/manual/de/function.fgets.php) Der Bonitätsanbieter Intrum hat hier eine sehr unperformante Methode sendRequest() – welche bei jedem Login ganze 3 Sekunden braucht um einen Response zusammen zu bauen.

Hier muss nun der Pluginentwickler etwas anpassen oder man muss selbst den Response zusammenbauen.

Ich zeige euch das ganze, damit Ihr seht wie schnell Ihr gewisse Bottlenecks mit einem APM Tool finden könnt. Am Anfang brauch das etwas Übung, aber auf lange Sicht kann man nur so vernünftig optimieren (lokale Profiler wie Xdebug und FroshProfiler liefern hier zwar auch Ergebnisse, aber haben oft keine Timeline)

Ein letztes cooles Feature in Tideways ist das forcen des Profilings – dazu installiert Ihr euch die Chrome Extension und loggt euch in euren Account ein. Nun könnt Ihr entweder die aktuelle Seite profilen oder einfach 15 oder 60 Sekunden wählen um ALLE Calls aufzunehmen (Ajax Calls, welche Ihr so nicht triggern könnt).

Alerting

Tideways

In Tideways heißt das ganze „Notification“ – dort könnt Ihr z.B. einstellen das bei eine Response Time von über 700ms eine Warnung raus geht – über folgende verfügbaren Channels:

  • Email
  • IRC
  • Hipchat
  • Slack
  • OpsGenie
  • Flowdock
  • Webhook
  • PagerDuty
  • MicrosoftTeams

New Relic

In New Relic geht das ebenfalls und heißt dort „Alerts“ – finde es etwas intuitiver und sauberer intergriert:

  • Email
  • Campfire
  • Hipchat
  • Slack
  • OpsGenie
  • VictorOps
  • Webhook
  • PagerDuty
  • xMatters

 

Fazit

Wenn Ihr mehrere Subshops in Shopware habt und diese auch tracken möchtet, solltet Ihr auf jeden Fall Tideways nutzen. Aktuell habe ich noch keine Möglichkeit in New Relic gefunden es genauso abzubilden, selbst vom SalesRep habe ich noch keine Rückmeldung bekommen (er wollte bei einem Engineer nachfragen).

Beide haben so Ihre Vor- und Nachteile. New Relic kann in Kombination mit Ihren anderen Produkten eine komplette Operation monitoren und analysieren. Das Produkt Browser prüft auf Javascript Error und ähnliches. Infrastrukture übermittelt den Gesundheitsstatus aller Server und in Insights läuft alles zusammen und kann über Queries interpretiert werden.
Günstig ist das ganze allerdings nicht – bei 4 größeren Servern ist man schnell bei 600 USD und wenn man noch andere Funktionen neben APM nutzen möchte wird es nochmal teurer.

Tidways dagegen ist bei 159€ gedeckelt – so viele Hosts/TLDs wie Ihr wollt, 14 Tage Data Retention (50k Traces im Monat) und bis zu 10 Servern. Dafür bekommt Ihr eine ordentlich vorkonfigurierte APM (für Shopware).

Für kleine und mittelständische Unternehmen genau das richtige – wenn Ihr einen kleinen Shop habt könnt Ihr auch mit der Lite Version anfangen (39€) und wenn Ihr skaliert dann einfach auf die Basic Version gehen (by the way – das Naming ist komisch – Basic und Standard sind doch sehr ähnlich – warum nicht Pro oder Enterprise?)

Wenn Ihr nach eine Komplettlösung sucht und +50 Millionen Umsatz macht, ist vielleicht New Relic die richtige Lösung. Ihr solltet dann aber auch Inhouse hosten oder wenigstens einen Cloud Service nutzen, sonst lohnt sich der Mehrwert von Infrastructure und Co. nicht.

 

Eventuell füge ich in Kürze noch Datadog hinzu (sobald APM auch für PHP funktioniert) oder schaue mir noch Backfire.io an. Dies habe ich schon einmal genutzt, aber nur im lokalen Staging Betrieb und gefallen hat es mir irgendwie nicht.

 

 

2 Antworten auf „APM für Shopware | Tideways, New Relic und Datadog“

  1. Hallo Micha,

    wo finde ich denn den Beitrag dazu
    “ Es gibt scheinbar auch Wege über Github Repos diese Funktion zu nutzen. Darauf gehe ich aber in einem anderen Artikel ein.“

    Ich habe auch bereits New Relic getestet und auch Tideways. Jetzt wollte ich mal Datadog testen, aber ich konnte noch keinen Weg finden, dies ans Laufen zu bringen.

    Hast du vllt hilfreiche Links für mich?

    Gruß
    Max

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert