PHP 8.0 und Performanceoptimierung mit Tideways

Im Interview erzählt Benjamin Eberlei, Gründer und Geschäftsführer von Tideways, über die Neuerungen im Produkt und gibt wichtige Tipps im Hinblick auf PHP 8.0.

Bitte stelle Dich und Dein Unternehmen kurz vor

Ich bin Benjamin und Gründer der Firma Tideways. Tideways ist eine Software zum Messen der Performance von PHP-Systemen z.B. Shopsystemen wie Magento, Shopware oder auch Symfony-Anwendungen. Mit Tideways prüft man, wie schnell einzelne Seiten sind, welche Fehler auftreten und bekommt zudem Hinweise, wie man Performance-Probleme beheben kann.
Das Unternehmen gibt es jetzt seit 2016 - wir feiern also nächstes Jahr Jubiläum.

Wieso habt Ihr Euch auf die Performance-Messung von PHP-Systemen spezialisiert?

Ich hab in einem Unternehmen gearbeitet, in dem wir größeren Shop-Kunden dabei geholfen haben, Lasttests und Performance-Analysen zu machen. Hauptsächlich war das im Zuge der Vorbereitung für beispielsweise den Black Friday und das Weihnachtsgeschäft, oder aber bei Shop-Relaunches. Dabei haben wir geprüft, ob der (neue Shop) von der Performance auch das erwartete Volumen abfedern kann. Wir hatten dabei jedoch immer das Problem, dass wir zwar herausfinden konnten, wie viel Last der Shop vertragen konnte, aber nicht im Detail sagen konnte, wenn er das nicht konnte. Vor allem konnten wir aber auch nicht erklären, was die Gründe für eine fehlende Performance waren.
Wir haben dann angefangen, uns damit zu beschäftigen, wie man theoretisch für dieses Problem Lösungen finden könnte und sind bei der Recherche auf ein paar hilfreiche Open-Source-Tools gestoßen. Auf deren Basis haben wir dann kleinere Prototypen gemacht und daraus ist die Idee entstanden, dies in ein Produkt umzuwandeln - Tideways.

Wie viele Personen wart Ihr bei der Gründung und wie habt Ihr Euch entwickelt?

Ich habe damals bei der Firma Qafoo gearbeitet, die im Bereich PHP E-Commerce-Beratung gemacht haben. Zusammen mit Qafoo habe ich dann Tideways gegründet, wobei ich der einzige aktive Geschäftsführer und Gesellschafter bin. Aktuell sind wir zu siebt.

Was macht Tideways genau?

Tideways ist eine Erweiterung für PHP, die man auf den eigenen Server installiert. Tideways hängt sich dann in die verschiedene Schnittstellen rein, die PHP zur Verfügung stellt. Damit kann man dann die Performance messen und auf Fehler hin überprüfen.
Diese Daten sammeln wir von jedem Seitenaufruf, d.h. immer, wenn ein Besucher auf den Shop geht, misst Tideways die folgenden Punkte:

• Wie schnell war der Seitenaufruf?
• Welche Teile waren dabei schnell?
• Welche Teile waren langsam?

Dies macht Tideways nicht nur bei Datenbankabfragen und anderen Funktionen des Shopsystems, sondern auch an den Schnittstellen zu den Drittanbietern. Jeden einzelnen Bereich überprüfen wir auf seine Schnelligkeit.
All diese Daten werden dann in einem Zwischenprozess, den wir “Tideways Daemon” nennen, aggregiert und an unser Backend gesendet. Im Backend werden die Daten dann verarbeitet, entsprechend aufbereitet und dem Benutzer zur Verfügung gestellt. Hierfür nutzt der Kunde unser Web-Interface, wo man auf die entsprechenden Daten zugreifen kann, die kontinuierlich von der Kunden-Anwendung ins Backend gestreamt werden.

Dieser Zugriff erfolgt jedoch nicht live, es sind also keine Echtzeitdaten. Allerdings sehr nah dran, an dem, was gerade passiert.

Kann der Kunde seine Performance-Probleme mit Tideways lösen?

Wenn der Kunde merkt, dass seine Seite langsamer wird, kann er in sein Dashboard gehen und sich schon mal einen Überblick verschaffen, woran der Performance-Verlust liegen könnte, denn wir machen die Probleme mit unserer Software sichtbar. Für eine Reihe von Problemen können wir sogar schon konkrete Lösungsvorschläge machen. Aber natürlich ist die Software zu komplex, um das komplett automatisiert zu machen.

Wie unterscheidet sich Tideways von anderen Profilern?

Zu dem Zeitpunkt, als wir Tideways gegründet haben, gab es nur New Relic - Blackfire ist erst kurz danach erschienen. Einer der Gründe, warum wir Tideways entwickelt haben, ist die Tatsache, dass New Relic nicht unseren Anforderungen genügt hat.

New Relic selbst hat keinen wirklich guten Profiler, denn man kann ihn nicht so detailliert steuern, wie man das mit unserer Software tun kann. Bei uns hat der Kunde sehr viel Kontrolle über den Profiler, um herauszufinden, was genau den Performance-Abfall verursacht. Bei New Relic hingegen gibt es keine Möglichkeit der persönlichen Einflussnahme, denn das System arbeitet komplett automatisiert und nimmt einem damit die Entscheidung ab, was angezeigt wird.

Im Gegensatz dazu ist Blackfire auch einen Profiler, bei dem man auch sehr viel Kontrolle über die Daten hat, die man sehen möchte. Aber in Blackfire ist es immer notwendig, dass der Entwickler die Sammlung von Daten auslöst, das erfolgt nicht per se automatisiert. Es gibt auch automatisierte Prozesse in Blackfire aber im Prinzip werden dabei nie die Daten von realen Nutzern gemessen. Es ist quasi so, dass Blackfire oder der Entwickler von außen auf den Server zugreifen, den Profiler auslösen und dann die Performance sichtbar wird, die der Entwickler bzw. Blackfire gesehen hat. Somit wird also nicht die Performance von echten Benutzern gemessen.

Unsere Philosophie ist jedoch, dass man auf das gucken muss, was reale Nutzer sehen, d.h. man muss die Performance anhand der realen Daten sehen. Denn wenn man das nicht tut, dann kann man nie sicher sein, dass die gesammelten Daten auch der Realität entsprechen, was nicht sehr erfolgversprechend ist.

Unsere Idee war daher ein “neues” New Relic zu entwickeln. Das heißt, wir wollten ein kontinuierliches Monitoring, die Messung jedes einzelnen Request und die Aggregierung der Daten, sodass wir die gesamte Performance der Anwendung darstellen können. Und - ganz wichtig - der Entwickler sollte die Möglichkeit haben auf Wunsch den Profiler “zu übernehmen” und detailliert Daten über einzelne Seitenpunkte zu sammeln.

Das ist das, was Tideways besonders macht: Wir haben den Monitoring-Aspekt von New Relic kombiniert mit dem Profiling-Aspekt von Blackfire.
Eine weitere Besonderheit ist sicherlich, dass wir uns auf PHP fokussiert haben, während die anderen Profiler auch andere Sprachen unterstützen. Das mag auf den ersten Blick eine ungewöhnliche Entscheidung von uns sein, aber um einen Profiler zu schreiben, braucht es ein extremes Spezialwissen über die entsprechende Sprache. Und wir haben diese hohe Expertise im Bereich PHP - und würden unseren eigenen Ansprüchen in den anderen Sprachen nicht unbedingt gerecht werden.

Zudem ist es aus Sicht des Marktes so, dass wir mit E-Commerce Unternehmen des Mittelstands zu tun haben und weniger mit DAX-Unternehmen oder Großkonzernen. Unserer Erfahrung nach nutzt ein Großteil dieser Firmen PHP und da dieser Markt sehr groß ist, sehen wir nicht unbedingt die Notwendigkeit, unsere Software um weitere Programmiersprachen zu erweitern.

Apropos Sprachen: 50 Prozent unserer Kunden sind aus Deutschland und die anderen 50 Prozent sind aus dem ganzen Rest der Welt. Und das meint dann wirklich überall. Ich glaube sogar, wir jetzt tatsächlich auf jedem Kontinent mindestens einen Kunden haben.

Was uns noch von den anderen Profilern unterscheidet, ist unser Fokus auf die Messung von Applikationsperformance. Andere Tools messen teilweise auch die Server-Performance: wie viel Speicherplatz hat der Server, wie viel CPU und RAM wird benutzt etc. Unsere gemeinsamen Kunden können natürlich davon profitieren, dass maxcluster diese serverseitige Performance-Messungen macht. Ich kann daher verstehen, dass einige Nutzer den Wunsch haben, ein Tool zu haben, dass alles kann, aber meiner Erfahrung nach sind diese “Alleskönner” leider auch nicht über alle Bereich hinweg wirklich gut. Und das kann dazu führen, dass man mit diesem Tool einem Problem nicht auf die Schliche kommt, weil die letzten 5 bis 10 Prozent an Detailtiefe fehlen.

(A.d.R.: Einen Vergleich zwischen den genannten Profiling Tools gibt es in unserer Blogserie: https://maxcluster.de/blog/2017/04/flaschenhaelse-erkennen-mit-3-effizienten-profiling-tools)

Warum bist Du Contributor bei PHP 8.0 geworden?

Das größte Projekt, an dem ich auch jetzt noch mitwirke und einer der Haupt-Contributors bin, ist Doctrine. Das ist eine Datenbank-Abstraktion, also eine Bibliothek, um auf Datenbanken zuzugreifen.

Aber eigentlich habe ich schon seit 2008 an verschiedenen Open-Source-Projekten mitentwickelt und diese waren auch immer in PHP geschrieben. Außerdem habe ich viel am Symfony-Framework gemacht. Durch meine Arbeit bei Tideways habe ich dann auch gelernt, wie man PHP als Sprache selber verändert.

PHP ist in C geschrieben, also einer anderen Programmiersprache, die von der Komplexität deutlich höher ist. Als Nutzer von PHP - Tideways selbst nutzt PHP - und durch meine Arbeit an Open-Source-Projekten, bin ich immer wieder auf Features gestoßen, bei denen ich dachte, dass sie auch in PHP selber interessant wären. Und da hab ich dann angefangen, mich damit zu beschäftigen, wie ich die beisteuern kann.

Durch meine Arbeit an Tideways kannte ich bereits einige der PHP-Entwickler, die kontinuierlich an PHP immer mitarbeiten und dadurch habe ich so ein bisschen den Einstieg bekommen, mich daran zu versuchen. Vor knapp zwei Jahren habe ich dann angefangen, die erste Änderung beizutragen. Die jetzt nicht gerade klein war, aber mir die Möglichkeit gegeben hat, mich ein bisschen auszuprobieren. Thomas Weinert und ich haben dafür eine bestehende Schnittstelle, die DOM XML-Schnittstelle, um neue Funktionen erweitert. Gibt es übrigens auch schon für PHP 8.0. Danach habe ich zusammen mit Martin Schröder ein größeres Feature beigesteuert: Attributes.

Das Spannende an PHP ist, dass es sich um ein demokratisches Open-Source-Projekt handelt. Das bedeutet, dass alle Contributors die Möglichkeit haben, ob Änderungen durchgeführt werden oder nicht. Das wiederum heißt, dass ich als Contributor meine geplante Änderung beschreiben, einen Prototyp entwickeln und ein Design-Dokument erstellen muss und erst dann zur Abstimmung freigeben kann. Der Vorschlag wird dann häufig mehrere Wochen diskutiert und dann wird abgestimmt, ob diese Änderung tatsächlich angenommen oder doch abgelehnt wird. Das hat teilweise eine regelrecht politische Komponente und in diesem Prozess muss man sich natürlich auch erst einmal wiederfinden.

Dieser Prozess, der teilweise Wochen andauern kann, greift natürlich nur bei neuen Features. Wenn es darum geht, Fehler zu beheben ist die Vorgehensweise deutlich schneller.

Warum ich jetzt speziell an PHP arbeite, hat aber zwei Gründe. Zum einen kann man die Arbeit als strategische Investition für unser Unternehmen sehen. Dadurch, dass Tideways so stark mit PHP korreliert, ist es für uns einfach wichtig zu wissen, wie es funktioniert. Und die Vernetzung mit anderen Contributors verhindert natürlich auch, dass wir den Anschluss und damit auch unsere Lebensgrundlage verlieren.

Zum anderen ist die Entwicklung an PHP für mich einfach interessant und spannend, weil das - zumindest für mich - eine große Herausforderung ist. Es ist schwierig und man muss sorgfältig sein, dafür erreicht man aber auch viel mehr Leute, weil PHP einfach von sehr vielen genutzt wird. Schön ist aber natürlich auch, dass ich mir dadurch Wissen aneigne, dass ich auch in meinem Unternehmen nutzen kann, sodass ich mittlerweile natürlich auch die Möglichkeit habe, Projekte während meiner Arbeitszeit weiterzuentwickeln.

Wie bewertest Du die Neuerungen in PHP 8.0?

Man kann die Änderungen in verschiedene Gruppen einteilen und im Prinzip ist es so, dass PHP 8.0 weiterführt, was PHP 7 vor fünf Jahren angefangen hat. Es geht darum, dass die Sprache mehr Features bekommt, um eine bessere Typisierung zu ermöglichen, damit man bei einer Variablen besser beschreiben kann, um welchen Typ es sich handelt.
In PHP 8.0 gibt es das neue Feature “Union Types”, meiner Meinung nach ein ganz großes Feature von PHP 8.0 (A.d.R.: Dieses und mehr Feature werden in unserem PHP 8.0-Blogartikel ausführlich behandelt) und war eines der ersten RFCs, die schon vor über 1,5 Jahren durch die Contributor akzeptiert worden ist. Darüber hinaus gibt es noch eine Reihe weiterer, kleinerer RFCs, die auch die Typisierung verbessern.

Und schon in PHP 7 wurde damit begonnen, eine Reihe von alten Features abzuschaffen, die entweder nur wenig bis gar nicht genutzt wurden, oder Inkonsistenzen aufwiesen. Das treibt PHP 8.0. dann noch mal deutlich weiter. Inkonsistenzen in der Sprache wurden entfernt und die Sprache hat eine deutlich bessere interne Dokumentation darüber bekommen, welche Typen von einzelnen Funktionen angenommen und zurückgegeben werden. Alles wurde konsistenter gemacht und einige Altlasten wurden wirklich aufgeräumt. Das bedeutet im Umkehrschluss aber auch, dass sehr alter Code nicht ganz einfach auf PHP 8.0 zu migrieren sein wird.

Macht es PHP 8.0 Einsteigern einfacher?

Anfangs habe ich das nicht gedacht, aber mittlerweile glaube ich das auch.
PHP war ja eigentlich immer als Sprache gedacht, in die Entwickler leicht einsteigen können. Und das ist auch so. Allerdings kann man sich dabei auch schnell leicht “in den Fuß schießen”. Es gibt immer wieder Kleinigkeiten, bei denen man schnell mal ungewollt eine Sicherheitslücke einbaut, weil man im Detail nicht weiß, was man eigentlich genau machen sollte. Das finde ich übrigens prinzipiell nicht so schlimm, da man dadurch ja auch lernen kann.

Jetzt ist die Sprache sicherlich einen Tick komplizierter und verzeiht einem auch nicht mehr so viel. Bedeutet für einen Anfänger, dass er vielleicht schneller auf Probleme stößt, die er beheben muss. Doch jetzt gibt es dafür viel bessere Dokumentationen und insgesamt viel weniger Inkonsistenzen, sodass man PHP noch leichter lernen kann.
Mit der neuen Version wurden auch einige Sachen tatsächlich gelöst, die PHP einen schlechten Ruf bei Programmierern anderer Sprachen eingebracht haben. Dieser Prozess wurde bei PHP 7 gestartet und wird bei PHP 8 und deutlich weitergeführt. Und ein Ziel ist natürlich auch - auch wenn es nie ausgesprochen wurde, weil das System so demokratisch ist und niemand es steuert - junge Leute dafür zu gewinnen. Ansonsten würden ja irgendwann nur noch “alte Menschen” daran programmieren und nicht mehr viel Neues entwickeln, sodass die Sprache immer weniger weiterentwickelt werden würde. Ich denke, dass viele Sachen in PHP 8.0 drin sind, die dazu führen, dass auch junge Entwickler begeistert davon sein werden, diese Sprache zu verwenden - und vielleicht nicht mehr so schlecht gegenüber ihren Freunden dastehen würden ;-).

Wie denkst Du über den JIT-Compiler?

Für mich gehört das in die zweite Gruppe von neuen Features, bzw. der zweite große Block ist der Just-in-time-Compiler (JIT-Compiler). Im Prinzip ist es auch eines der Features, warum man eine Major Version released hat und keine weitere Version von PHP 7.

Meiner Meinung nach ist das ein sehr spannendes Feature und ich bin gespannt, wie Leute das benutzen werden und welche Erfahrungswerte man zusammentragen wird. Wichtig ist, dabei zu bedenken, dass dies jetzt das erste Release ist und die PHP-Entwickler auf Feedback angewiesen sind, wie der JIT-Compiler in realen Anwendungen funktioniert.
Erste Tests haben ergeben, dass die Performance-Verbesserungen von Anwendungen, die im Web laufen, wie z.B. Magento-Shops oder Shopware-Shops mit Symfony-Anwendungen, sehr klein sein werden. Doch das kann sich in Zukunft natürlich noch verbessern.

Tatsächlich sind aktuell aber der Haupt-Use Case für den der JIT-Compiler konsolengetriebene Anwendungen, d.h. Anwendungen, die sehr viele mathematische Berechnungen machen und sehr viele Daten verarbeiten.

Vermutlich denken viele, dass der JIT einfach viele Daten verarbeitet kann, es ist aber wichtig zu wissen, dass die Verarbeitung beim JIT-Compiler per PHP erfolgen muss. Das bedeutet, dass man PHP-Code bräuchte, der schneller wird, damit auch eine schnellere Verarbeitung möglich ist. Wenn ich beispielsweise eine Bibliothek habe, die Bilder verarbeitet, ist dieser Code meist in C geschrieben. Das ist teilweise schon fünfzig Mal schneller als PHP und wird auch durch den JIT nicht schneller. Das Gleiche gilt für Anwendungen für Datenbank-Abfragen, die auch nicht in PHP Code geschrieben sind - sie werden durch den JIT-Compiler nicht schneller.

Ich glaube daher, dass es anfangs eine längere Phase geben wird, in der man ausprobieren muss, welche Anwendungen überhaupt vom JIT profitieren werden. Und dann muss dieses Feedback dringend zurück an die Entwickler, die am JIT arbeiten, um diesen zu verbessern.

Bei einem Just-in-time-Compiler ist es ja so: So wie PHP jetzt funktioniert, wird der Code zur Laufzeit auf einer virtuellen Maschine ausgeführt, was natürlich auch bestimmte Performance-Qualitäten mit sich bringt. Der JIT-Compiler erkennt den PHP-Code, der verbessert werden kann, indem er aus der virtuellen Maschine herausgenommen und in maschinennäheren Code übersetzt wird. Man muss sich das so vorstellen, dass PHP auf einem sehr hohen Level ist und sich darunter viele Schichten befinden, die schneller sind. Das Ziel ist also, genau die richtigen Bausteine zu finden, die das Konstrukt schneller machen, denn nur dann wird es auch performanter.

Hinsichtlich der Performance gibt es aber ein weiteres Problem und das entsteht beim Wechsel des Codes von PHP in den JIT-Code und vice versa. Das ist ja quasi wie eine Übersetzungs-Nahtstelle. Die schwierige Aufgabe des JIT ist es nun, die richtigen Teile für die Optimierung zu finden, damit der Performancegewinn nicht durch die “JIT-Übersetzungen” aufgehoben wird.

Und ich denke, dass das die Hauptschwierigkeit bei der Entwicklung eines JITs ist: Man kann ihn nur verbessern, wenn man ihn nun mit realen Daten ausprobiert und diese Daten auswertet. Das bedeutet aber auch, dass es sich hierbei um einen iterativen Optimierungsprozess handelt und man mit einer nicht so perfekten Lösung startet, die sich über die Zeit immer weiter verbessern wird und dann auch für deutlich mehr Nutzer nützlich sein wird. Der erste große Schritt ist getan: Der JIT-Compiler ist vorhanden und kann schon die ersten Übersetzungen durchführen.

Meiner Meinung nach ist dieser erste Schritt schon beeindruckend, denn es ist wirklich ein massives Projekt. Und man muss sich als Nutzer vor Augen führen, dass es beim Wechsel von PHP 5 auf PHP 7 quasi eine 50 %ige Performancesteigerung gab, von der jeder kostenlos profitiert hat. Beim JIT wird das nicht kostenlos sein, denn um die Performance so stark zu verbessern, muss man viel Arbeit investieren, ihn gut kalibrieren und auch viel ausprobieren.

Habt Ihr bei Tideways Änderungen in Bezug auf PHP 8.0 vornehmen müssen?

Wir haben Mitte November unsere neue Version released, die bereits PHP 8.0 unterstützt.
Unser größtes Projekt bei diesem Release steht im Zusammenhang mit dem JIT-Compiler, denn es war nicht möglich Performance-Messungen des Codes durchzuführen, der durch den JIT durchgeht.

Man muss ich das so vorstellen: PHP ist die virtuelle Maschine und der JIT ist eine komplette, zweite PHP-Implementierung, die daneben liegt. Aber natürlich funktioniert der JIT mit einem gänzlich anderen Mechanismus, sodass sämtliche Schnittstellen, die wir in Tideways verwendet haben, nicht mehr funktionieren. Ob Performance-Messung oder Fehler-Detektion, alles existiert in der “neuen JIT-Welt” nicht mehr.

Also haben wir neue APis entwickeln müssen, die es möglich machen, sowohl “gejitteten” als auch “nicht-gejitteten” Code - also regulären, alten Code - mit denselben Schnittstellen zu messen. Unsere Kunden können sich also auch bei PHP 8.0 schon auf valide Daten verlassen.

Hast Du drei wichtige Tipps für die Nutzung von PHP?

Die letzten PHP-Versionen haben, wie bereits beschrieben, viele neue Features und Syntax bekommen. Davon profitiert man natürlich sehr, denn der Code wird knapper, kürzer, aber auch sicherer. Doch was macht man mit dem ganzen alten Code?

Wir bei Tideways und auch bei anderen Projekten, die ich begleitet habe, haben angefangen, viele Code-Änderungen zu automatisieren. Dieser Prozess wird natürlich vorangetrieben, durch ein paar Tools, die entwickelt wurden und von denen ich hier einige empfehlen kann:

Das erste, einfachste und vermutlich auch bekannteste ist der PHP Code Sniffer. Den gibt es zwar schon lange, aber der kann jetzt auch immer besser Änderungen automatisieren. Man kann damit beispielsweise den vorhandenen Code an die neuen, modernen Formatierungsstile anpassen. Außerdem kann man einzelne, neue Features einführen, oder Code, der als Features nutzt, in neue Features umwandeln, ohne ihn kaputtzumachen.

Das zweite ist eine Bibliothek, die das noch viel stärker vorantreibt - Rector. Damit hat man die Möglichkeit sehr gezielt zu sagen, dass man bestimmt geschriebenen Code in der eigenen Codebasis, komplett durch eine neue, bessere und modernere Syntax ablösen möchte. Man kann somit Code, der alte Features nutzt, komplett auf die neue Version migrieren - und das größtenteils automatisch. Natürlich muss man das immer noch überprüfen, aber die Migration ist mittlerweile schon sehr sicher.

Und meine dritte Empfehlung sind Tools, die bereits die modernen Features und die stärkere Typisierung nutzen, um automatisch Bugs und Fehler zu erkennen. Bei diesen Tools wird geprüft, ob der Typ, den ich an einer Stelle zurückgeben, auch mit Funktionen an anderer Stelle kompatibel ist. Diese Informationen gab es in PHP früher nicht, sind aber mittlerweile verfügbar. Früher war es dann so, dass sich der Fehler irgendwann bemerkbar gemacht und das Programm zum crashen gebracht hätte. Die neuen Tools erkennen diese Fehler nun vorab automatisiert, nur durch Lesen des Codes. Da gibt es zwei, drei bekannte Tools: Psalm, phpstan und Phan. Die machen im Großen und Ganzen dasselbe und unterscheiden sich nur minimal voneinander. Wir nutzen diese bei Tideways auch schon automatisiert und stellen fest, dass damit sehr viele Fehler erkannt werden.
Und all diese genannten Tools sind im Grunde genommen erst durch die neuen modernen Features von PHP sowie die starke Typisierung möglich geworden.

Als Partner von Tideways kann die aktuelle Software mit wenigen Klicks in unserem Managed Center konfiguriert werden. Sollten Sie Rückfragen haben oder weitere Informationen benötigen, wenden Sie sich gerne an unseren Service unter der Nummer 05251/414130 oder per E-Mail support@maxcluster.de.

Veröffentlicht am 14.12.2020 | NM