Gut.
Es geht weiter.
Der Christoph wird euch jetzt was überPerformance von Webseiten erzählen und wie
man das hinbekommt mit 500.000Attachments.
Genau.
Wundert euch nicht, die Folien sind aufEnglisch.
Ich werde den Vortragnochmal auf Englisch
halten, Ende nächstenMonats in den Niederlanden.
Den Vortrag halte ich aber auf Deutsch.
Der Vortragstitel heißt, wie kriege icheine Webseite schnell, obwohl sie
500.000 Anhänge hat.
Ich habe im Mai einen neuen Job angefangenund das war mehr oder weniger so.
Hier Christoph, das ist unsere Webseite.
Wer reingucken will, das ist bonedo.de.
Da kommt auch gleich zwischendurch nocheinmal ein Screenshot davon.
Das ist ein Musikermagazin.
Da sind viele, viele Bilder drin.
Es sind, glaube ich, 200.000 Bilder und300.000 Audio-Files.
Das Frontend war adäquat schnell.
Es ist halt schön mit Caching,mit allem Zipp und Zappel.
Also das Frontend.
Achso, das sind die da hinten.
Okay.
Wir haben keine Audio-Probleme.
Wir haben Audio-Probleme, die kommen dahinten von dem anderen Track.
Ja, Problem war, das Frontend war schnell,das Backend nicht.
Fangen wir doch erstmal mit mir an.
Wer bin ich denn eigentlich?
Ich bin der Christoph.
Ich bezeichne mich als WordPress- undPHP-Spezialist.
Ich habe Ende der 90erangefangen, irgendwas mit Web
zu machen und habe daauch erste Projekte gestartet.
Eins davon existiert heute noch und ist inseiner Nische nach wie vor führend.
Im Laufe meiner Karriere habe ich unteranderem an Projekten gearbeitet,
die mehrere Millionen Page-Impressions proMonat hatten.
Und da habe ich vonTeamentwicklung über
Architekturplanung und soweiter ziemlich alles gemacht.
Und ich arbeite jetzt in Iserlohn für einekleine Agentur.
Ihr findet mich aufLinkedIn, wenn ihr mir folgen
wollt, wenn ich mal irgendwelchenContent posten würde.
So, ich nehme jetzt mal hier das Dingsrein.
Ja, das Projekt, ich hatte gerade schongesagt, es heißt bonedo.de.
Es wurde ursprünglich als TYPO3 gestartet,2020 als WordPress neu gestartet.
Wir haben ungefähr 30.000 Posts
in unterschiedlichen Post-Types.
Und wie gesagt. Ach, guck mal,es war falsch rum.
250.000 Audios und 300.000 Bilder.
Und Frontend-Speed okay, Backend-Speedterrible.
Und ich sollte irgendwo links klicken.
So, wir haben hier ein paar Zahlen vorher.
Die Folie kriegen wir am Ende nochmal mitden Nachher-Zahlen.
Der Heartbeat brauchte ungefährzweieinhalb Sekunden.
Saving Post, ich habe gesagt terrible.
Sagt, schmeißt mal Zahlen in den Raum,was wie lange dauert es schätzungsweise,
wenn ihr auf den Beitrag drückt,bis der Beitrag gespeichert wurde.
Irgendwelche Zahlen?
Eine Minute ist verdammt gut, ist nahdran, ein bisschen zu langsam.
Es sind nur 40 Sekunden.
Aber wenn ein Beitrag viele Bilder hat,konnte der auch die Minute erreichen.
Beitrag öffnen, acht Sekunden.
Volleditierbar, 15 Sekunden.
Und das sind wirklich so Zahlen,wo wir gesagt haben...
Ja, wir haben ein Feedback-Tool im Backendund da hat uns ein Redaktionsleiter auch
bitterböse Mails drüber geschickt.
Der hat am Ende über das.
Über eine E-Mail an den PO geschickt.
Boah geil, was habt ihr denn mit der Seitegemacht?
So schnell ist die Seite im Relaunch nichtmehr gewesen.
Das ging runter wie Öl.
Nicht nur für mich, auchfür den PO, denn der PO
hatte schon zwischendurchAngst vor der Redaktion.
So, worüber wir hier nicht sprechen.
Frontend Caching, Object Caching,Server Setup und Scaling.
Das ist alles vorher da gewesen.
Das habe ich nicht angefangen.
In Großteil.
Eine kleine Änderung.
Wir haben ein bisschen was am Server Setupgemacht.
Aber das sind Sachen,die ich nach draußen
herausgegeben habe, wowir das Ops-Team haben.
Und das habe ich in dem Detail nichtangefasst.
Das heißt, wer das hören wollte,ist hier falsch.
Aber wir werden schon definitiv was findenfür euch.
So.
Topics.
Es gibt einen Punkt Null.
WordPress Plugins für Profiling.
Das sind die Topics, über die wirsprechen.
Eine kleine Einung.
Für die Spannungskurve habe ich die Folie8 und vor die Folie 6 und 7 gezogen.
Ihr werdet nachher sehen, warum.
So.
WordPress Plugins fürs Profiling und fürDebugging.
Keine großen unbekannten.
Query Monitor.
Debugbar.
Debugbar Actions.
Filter Add-on.
Rewrite Rules Inspector.
Die haben an vielen Stellen verdammt guteDienste gemacht.
Aber sie haben mir halt nicht bis zum Endegeholfen.
Die helfen.
Viel mehr will ich dazu gar nicht sagen.
So.
Beim Heartbeat haben wir ein bisschenoptimiert.
Und zwar habe ich den Heartbeat runtergestellt,dass er nicht ganz so oft abfeuert.
Weil er halt viel lädt.
Und realistisch gesehen wenig tut.
Im Frontend habe ich ihn für ziemlichnutzlos gehalten.
Deswegen habe ich ihn im Frontend auf eineStunde hochgezogen.
Dazu hatte ich gefunden, dass es dasPlugin Debugbar Control gibt.
Was mittlerweile zu WP Rocket gehört.
Und anhand der Forumsartikel als ziemlichunmaintained darstellt.
Ich habe einfach nur ein paar Fragmenterausgenommen.
Bei uns eingebaut.
Details findet ihr in dem Gist auf meinemProfil.
Oder im QR-Code.
Hier kommt jetzt eine Folie.
Wenn ich die wirklich umgesetzt hätte.
Das hätte mir einen Schritt am Endegespart.
Dieses ganz wunderbare PluginIndex WP MySQL for Speed.
Das haut Indizes insbesondere auf diePostmeta-Tabelle drauf.
Das habe ich durch Recherche undUnterhaltung gefunden.
Das wurde mir von einem sehr guten FreundHendrik Lösen empfohlen.
Das hätte viel geholfen.
Wir haben es auf vielen Projekten auchschon im Einsatz.
In dem Projekt war es nicht aktiviert.
Wenn ihr es noch nicht installiert habt,evaluiert es.
Das hilft.
Was ich dann tatsächlichan einigen Stellen gemacht
habe, ist, ich habeCustom Tables eingefügt.
Das heißt, anstatt über Daten in derPostmeta zu gehen, habe ich eine eigene
Tabelle angelegt, habe sie über den Filterposts_clauses reingehängt und konnte
dadurch Meta-Querys mit einem simplen Joinersetzen.
Das ist teilweise der Unterschied imFaktor 10, Faktor 100 und mehr.
Damit habe ichstreckenweise das Backend
beschleunigt, streckenweisedas Frontend beschleunigt.
Allerdings reden wir an der Stelle überdie Beschleunigung von Queries.
Dadurch habe ich alleSlow-Querys entfernt
gekriegt, die mir vorherdebugbar angezeigt wurden.
Dann wurde mir auch der Blog von SteffenDressler empfohlen.
Der wuselt auch hier irgendwo rum.
Ich glaube, hier sitzt er nicht.
Steffen, bist du hier?
Nein, da ist Steffen da drüben.
Wir haben für ein Projekt, wo sie eineWooCommerce-Seite mit einer Million
Produkten online gestellt haben, ganz vielan den Taxonomie-Updates rumgeschraubt.
Im Nachhinein glaube ich, dass ich diesenSchritt hätte sein lassen können,
weil ich hinten raus etwas entfernt habe.
Während ich das umgesetzt habe,war das sehr sinnvoll, denn bei jedem
Abspeichern werden im ZweifelsfallTaxonomie-Updates gemacht.
Deswegen, wenn ihr viele Taxonomien habt,kann das verdammt viel bringen.
Hier kommen wir jetzt genau dazu, warumich den Schritt 4 hätte sein lassen dürfen.
Wir haben in unserem Projekt Legacy-Codedrin gehabt.
Und diesen Legacy-Code zu entfernen,dieser Legacy-Code hat etwa 10% Overhead
bei jedem einzelnen Seitenaufrufproduziert.
Das heißt, wenn ihr euereigenes Projekt durchguckt,
guckt mal, was ist toterCode oder ein totes Feature.
Es ist ja kein toter Code.
Der wurde ja benutzt und aufgerufen,aber er hatte keine Funktion.
In dem Fall wurde ein,
im Endeffekt, es war eine facettierteSuche, wo man filtern hätte können.
Und dafür wurden 1400 Taxonomien angelegt.
Nicht 1400 Terms, es waren 1400Taxonomien.
Jedes Mal.
Ich sehe, Thorsten lacht.
Guckt den Unterschiedim Zweifelsfall, wenn
ihr noch nicht versteht,wie schlimm das ist.
Wir haben es ausgebaut 10% schneller.
Nur deswegen.
Vor allem für ein kaputtes Feature.
Das war verdammt wertvoll.
Ja, aktueller Status.
Viel Kleinkram.
10, 20% Improvement.
Aber wenn wir nochmal überlegen,wir waren bei 40 Sekunden fürs Speichern.
20% Improvement auf 40 Sekunden.
Macht die Redaktion noch nicht happy.
Jetzt kommen wir zu der rausgezogenenFolie.
Ich hatte ein Problem.
Was sich am Endedarauf gezeichnet hat, dass
ich mit der Post-Meta-Tabelleein Problem habe.
Dafür habe ich dann.
Ich musste es erst mal finden.
Dann habe ich geguckt,wie ich es fixen kann
und habe dafür auchein Trac-Ticket eröffnet.
Das ist bereits gemerged in Trunk und wird,
in 6.7 im November rauskommen,
dass man die Funktion, die ich euchgleich zeige,
oder das Query, was ich euch gleich zeige,dass man das elegant umschiffen kann.
Außer natürlich, man benutzt direktIndex WP MySQL for Speed.
Dann braucht man es nicht.
So, dieses ganz wunderbare Query.
Thorsten, du bist raus.
Was schätzt ihr.
Das sieht total harmlos aus.
Was schätzt ihr bei 500.000 Attachments,wie lange braucht dieses eine Query?
Ich nehme,
Wetten an.
Zu lang ist richtig.
Okay, wie viel zu lang?
Komm, Thorsten, die anderen wollen nicht.
Sag eine Zahl.
Also es sind 500.000 Attachments in derDatenbank.
Es sind in Summe.
Das ist der Hauptgrund für die 40Sekunden.
Das ist richtig.
Verdammte 4 Sekunden.
Für ein Query.
Wenn dann 10 Attachments in dem Post drinsind, weil eine Galerie drin ist,
hast du deine 40 Sekunden.
Ich habe. Oh, so weitwollen wir noch nicht.
Ich habe es dann am Ende so gelöst, dassich dafür eine Lookup-Tabelle gemacht habe.
Und über andere Hooks reingehängt habe.
Und damit bin ich von 4 Sekunden auf 2Millisekunden runtergekommen pro Request.
Mit Index MySQL, mit dem Plugin,
kommen wir auf ungefähr die gleichePerformance -Optimierung.
Jetzt kommt die große Quizfrage.
Wie habe ich das gefunden?
Und zwar, ich habe es mit XhProf gefunden.
Das Einzige ist, XhProf hat ein paarProbleme.
Es wird bei DDEVzum Beispiel direkt mit
ausgeliefert, wenn ihrlokal mit DDEV installiert.
Da müsst ihr nur sagen, DDEV XhProf habtihr direkt da.
Das XhProf ist toll, wenn ich genau weiß,was ich profile.
Aber es zeigt mir eine beschisseneÜbersicht.
Es zeigt mir nicht, welche URL ich geradewirklich geöffnet habe.
Und es zeigt mir auch nicht, was unter derHaube sonst noch passiert ist.
So sieht XhProf standardmäßig aus.
Das heißt, ich habe hier meine Liste mitkryptischen Hashes, welche Runs ich hatte.
Und ein Run sieht so aus.
Da steht überhaupt nichts drauf,was da im Endeffekt passiert ist.
Und hier sehe ich jetzt MySQL-Query hat134.000 Mikrosekunden gedauert.
Und das auf 360 Requests verteilt.
Damit weiß ich, okay,ich habe ein Problem in
MySQL, aber ich weißnoch lange nicht welches.
Und dafür habe ich ein Toolset gebaut,was genau diese fehlenden Sachen löst.
Und ja, jetzt wird es lustig.
Das kann man jetzt nicht mehr lesen.
Das sind im Endeffekt die Log-Dateien,die ich rausschreibe.
Da stehen jetzt solche lustigenInformationen drin, wie – das kriegen wir
aber noch gefixt hier – hier stehen dannInformationen drin, wann wurde der
gestartet, wie lange hat der im Endeffektgedauert, welche URL wurde aufgerufen,
wie viele Postvariablen, Referrer und soweiter und so weiter.
Da habe ich also schonmal die Informationen,
welche URL wurde im Detail aufgerufen.
Und hier unten, da haben wir denBösewicht.
Hier steht jetzt gerade Delta 136Sekunden.
Und da kann ich mir jetzt angucken,okay, dafür brauche ich diesen Hash.
Kann ich direkt darauf klicken.
Kleine Einschränkung, ichhabe mir noch nicht die Arbeit
gemacht, dass das Teilirgendwo ein Web-Interface hat.
Ich kann es nur über ein Terminalaufrufen.
Aber, schon mal zwei Folien vorgegriffen,das Ding ist Open Source auf GitHub und es
ist zum Weiterentwickeln gedacht.
Hier haben wir jetzt nämlich genau diesenFall.
Hier habe ich jetzt den Fall, dass ichhier sehe, okay, hier habe ich einen,
hier habe ich zwei Screenshotsrausgezogen.
Der erste ist aus dem hier.
Der hat tatsächlich 16Sekunden gebraucht, weil
er für curl_exec 15Sekunden gebraucht hat.
Und im zweiten sehe ich, dass session_start16 Sekunden gewartet hat.
Dazu kommen wir gleich, wofür das gut war.
Dann habe ich einen Database-Log gemachtund im Database-Log habe ich ihm
beigebracht, speichere doch nur das ab,was länger als 0,1 Sekunde dauert,
kann man on demand mit derKonfigurationsvariable definieren,
dass man wirklich nur die problematischenDinger loggt.
Was schnell ist, bei 360 Queries möchteich nur die 10 haben, die langsam sind.
Parallel gibt es auch noch, also hier habeich genau, hier ist, wunderschön nochmal
ein Screenshot von meinem, unserem Freund,den ich euch gerade gezeigt habe.
Und hier ist nochmal der Proof.
Das Teil hat wirklich 6 Sekunden,beziehungsweise 2,5 Sekunden gedauert,
um zu laden.
Ähnlich gibt es nochmal das Gleiche fürHTTP Requests.
Für HTTP Requests muss danndas Plugin Debugbar installiert
sein und aktiviert sein, damiter die Daten auslesen kann.
Hier findet ihr das Toolset, wenn ihr esbenutzen wollt.
Ich lasse die Folie eben einen kleinenMoment hier stehen.
Der Clou an der Sache war halt,damit habe ich wirklich gefunden,
was beim Abspeichern passiert.
Denn wenn ihr im Editor, im Blog-Editorauf Abspeichern drückt, dann ist das nicht
wie beim Classic-Editor.
Ihr habt den einzigen Request und das Dinglädt neu und das Ding ist da, sondern beim
Abspeichern passieren je nachdem,wie ihr euer WordPress aufgesetzt habt,
schnell 10, 20 Requests unter der Haube,die hin und her geschoben werden und was
ich euch vorher gezeigt habe,ihr habt keine Chance zu wissen,
in welchem von den 10 Requestsist jetzt gerade euer Problem.
Und der letzte große Teil, was jetzt hierist, das, was ihr vorher gesehen hattet,
session_start, dass das dafür gesorgt hat,dass wir so ein Ramp-up hatten,
das Ding hat sich wirklich durchgezogen.
Wir hatten also einen Request,der lange gedauert hat und dann 16,
16, 16, 16 Sekunden nur, weil die alle aufsession_start gewartet haben.
Und das konnte ich darauf zurückführen.session_start, wenn ich es standardmäßig
laufen lasse, wartet bei Design darauf,dass er schreiben darf und fertig.
Das kommt in dem Fall von der NinjaFirewall.
Ich weiß nicht hundertprozentig,ob es ein Seiteneffekt
von irgendwas anderemgewesen ist oder nicht.
Als ich den Vortrag vor ein paar Wochenauf der FrOSCon gehalten habe,
kam dann der Zwischenruf, ja, das ist beiDesign, dass session_start wartet,
weil eine PHP-Session soll ja wirklichsynchron sein.
Okay, ja.
Ich hatte aber ein Problem damit,dass er wirklich gewartet hat,
denn ich will ja nicht,dass er darauf wartet und es
waren keine kritischenInformationen in der Session.
Lange Rede, kurzer Sinn.
Da kommt die eine Ausnahme zu der Folie amAnfang.
Wir haben ein Redis aufgesetzt und habendie Session im Redis speichern lassen,
wodurch wir das Problem komplett losgeworden sind, weil er dann jetzt nicht
mehr gewartet hat,bis der andere fertig
gewesen ist, sonderneinfach durchgelaufen ist.
Wir sind bei der Folie von vorhin.
Wir waren bei zweieinhalb Sekunden.
Was schätzt ihr?
Wo sind wir jetzt?
Die Hälfte.
Nee, weniger.
0,7.
Saving a post, Thorsten.
Post öffnen?
Zwei hast du gesagt?
War jetzt richtig.
Du darfst dir ein gratis Getränkunten nehmen.
Und voll editierbar?
Vier.
Und wie gesagt, nach den Änderungen,die wir hier gemacht haben, hat einer aus
der Redaktion, unserem PO, Bescheidgesagt.
Was habt ihr denn da gemacht?
Das ist verdammt geil.
So schnell war die Seite vorher nochnicht.
So.
Die vorletzte Folie.
Der Daniel hat ein Mikrofon und schießtlos.
Hallo Christoph.
Also erstmal Wahnsinn, dass du das sohinbekommen hast.
Also ich bin total baff, dass das jetzt sowirklich runtergedrosselt ist.
Ich habe eine Frage.
Wir haben uns vorhin ein bisschenunterhalten über ACF.
Also ich weiß, ACF ist ein Performance-Killer schlechthin, sagen wir mal so.
Aber jetzt, wenn man das verwenden muss,in der Hinsicht.
Was ist deiner Meinung nach der beste Rat,außer das Plugin jetzt irgendwie versuchen
rauszuschmeißen, irgendwie das zuoptimieren?
Also gibt's das?
Irgendwas, was du von deiner Seite sagenwürdest, diese Einstellung musst du am
besten vornehmen oder irgendwie in derDatenbank optimieren, dass das zumindest
von der Performance beigrößeren Webseiten mit,
sagen wir mal, 10.000Unterseiten oder etc.
ein bisschen stabiler läuft.
Ok, dazu direkt vorab.
Ja, in dieser Seite läuft ACF und ich habees auch noch nicht hingekriegt,
das rauszuschmeißen.
Tatsächlich einige derDaten, die ich dort drin
habe, habe ich redundantin der Datenbank drin.
Das heißt, ich habe sie, ich lasse sieüber ACF ganz normal in der Postmeta
speichern und speichere sie mir redundantüber einen Filter in einer Custom Table.
Das heißt, ich habe zum Beispiel einenFlag, was heißt hide on irgendwas,
ich weiß nicht mehr, hide this post.
Das habe ich redundant nochmal in derzusätzlichen Tabelle gespeichert,
um loszuwerden, dassich dafür ein Meta -Query
machen kann, sondernwirklich ein 1 zu 1 Join.
Ebenso wird in dieser Meta-Tabelle zumBeispiel, gibt es ein Flag, das ein
Artikel, ein sogenannter Container-Artikelist, das heißt, da gibt es dann noch unter
Artikel dazu und dass nur Container-Artikel dort angezeigt werden.
Das ist nicht ideal.
Ich habe noch keine 100% lösungan der Stelle für ACF gefunden
und ich habe mich auchnoch nicht tief da reingearbeitet.
Mein Kritikpunkt, den ich nachdreieinhalb, vier Monaten ich muss mit ACF
kämpfen habe, ist, ACF macht das Lebenviel zu einfach.
Und das ist definitiv mein Rat,wenn ihr ACF benutzt, nicht erst drauf
losklicken und dann überlegen,sondern erst überlegen und dann lösen.
Egal, ob mit ACF oder sonst was.
Denn das Problem ist, ACF macht es soeinfach, dass ich eine Lösung
zusammengeklickt habe, die ich vielleichtmit einem Gedankengang auf einer anderen
irgendwie andersabgespeichert hätte oder vielleicht
komplett anders gelöst hätteund gar nicht gebraucht hätte.
Das ist mein Rat an derStelle für im Endeffekt nicht
nur für ACF, sondern fürjedes Clicky-Bunty-Tool.
Wenn es zu einfach ist, macht man manchmaleine zu schnelle Lösung.
Frage beantwortet.
Hallo Christoph, danke erst für denVortrag.
Wirklich beeindruckend.
Mich würde interessieren, wie lange hastdu dafür Invest gebraucht, also wie viel
Zeitaufwand war das für dich, um dawirklich dahinter zu kommen und das dann
so hinzubekommen?
Das ist.
Die Frage ist an der Stelle nichthundertprozentig zu beantworten.
Es war halt, wie gesagt, da ist Onboardingmit drin, ins Projekt reinkommen,
das heißt ich bin wirklich komplettniegelnagelneu ins Projekt rein.
Ich glaube, nach zwei Monaten, um den Dreh,war ich an dem Punkt.
Ich habe am Anfang wirklich einfach imNebel gestochert und diesen Kleinkram wie
Meta -Querys rausgeschmissen und soweiter.
Das hat natürlich ingewisser Weise geholfen,
war aber ein Tropfenauf den heißen Stein.
Ich gucke gleich nach und sage dir einedefinitive Antwort, aber roundabouts nach
zwei bis drei Monaten, die allerdings,wie gesagt, Start beim neuen Arbeitgeber
und Onboarding in einem niegelnagelneuenProjekt beinhaltet haben.
Da hinter dir ist noch eine.
Eine Frage, also gibt es vielleicht nochvon deiner Seite, wenn man jetzt ein
Caching-Plugin nehmen muss,gegebenenfalls eine Empfehlung,
was du sagen könntest, daskönnte man verwenden, ohne jetzt
viel Schnickschnack irgendwoauf dem Server zu konfigurieren?
Darf ich bezahlte Plugins nennen hier,Thomas?
Nein, das ist nicht im Repository.
Ich benutze gerne ein bezahltes Plugin, wasso ein ähnliches Logo hat wie meine Firma.
Da ist das Logo nicht drauf.
Ja, wir benutzen WP Rocket.
Ob das jetzt die finale Empfehlung istoder nicht, ich kann dir an der Stelle
folgendes sagen, ich habe mal W3 TotalCache benutzt.
W3 Total Cache ist super, allerdings istes so kompliziert zu konfigurieren,
dass ich mir ganz wunderbar damit in denFuß geschossen habe und die Konfiguration
dafür gesorgt hat, dass ich bestimmteSeiten nicht mehr aus dem Browser Cache
meiner Anwender gekriegt habe.
Also von daher, W3 TotalCache ist fein, mit der Gefahr,
man kann sich damit ganzwunderbar ins Knie schießen.
Danke für den Vortrag.
Sehr interessant.
Hast du noch eine Frage?
Hast du noch eine Idee, was bei dem FullyEditable, das waren 15 Sekunden,
doch 15 Sekunden war es, was daausschlaggebend war?
Ist das nur bei Postsmit vielen Attachments
schon drin oder das warhalt quasi dann die Meta?
Also was bei dem Fully Editable durchausauch mit geschlagen hat, ist die Kollegen
haben Blocks mit ACF gebaut, die natürlichauch sehr reingeschlagen haben und da sind
wir noch dran, um einige davon in nativeBlöcke, in custom Blöcke komplett
umzuwandeln und Fully Editable habe ich ander Stelle definiert als keine Eieruhr,
weil irgendwas sei es Taxonomies oderim Post hat noch gelaufen.
Das war für mich Fully Editable.
Da weiß ich definitiv, die ACF Blöckewaren ein Problem.
Ja, okay.
Dann nur noch eine Sache, die ich imletzten halben Jahr gelernt habe für das
Debuggen oder Profilen von PHP Requests.
Ich weiß nicht, sagt dir die Exima PHPExtension etwas?
Nein.
Das ist von der Wikimedia Foundation.
Das ist eine Alternative zu XdebugProfiling oder XhProf.
Wenn du etwas lokal nachstellen kannst,dann kannst du die auch verwenden,
um es zu debuggen oder wenndu über die Cloud irgendwie quasi
kompletten Zugriff hast,kannst du es auch da installieren.
Das ist irgendwas, was ich jedem empfehlenwürde, der etwas debuggen muss oder möchte.
Also lass dich mal anzuschauen.
Also mir war es völlig neu, gibt es aberseit Jahren.
Exima von Wikipedia, Wikimedia.
Super, danke dir.
Da hinten haben wir noch eine Hand.
Thomas, wie viel Zeit haben wir noch?
Ja, danke.
Ich habe eine Frage.
Dieses Tool, was ihr gemacht, also entwickelthabt, das ist total nice, total cool.
Also muss man dafür fürganze VM, Zugriff haben oder
reicht es von der Nutzungvon Hosting Interfaces?
Um das Toolset benutzen zu können,brauchst du zwingend xhProf.
Und Shell Zugang im aktuellen Zugang.
Das heißt, hast du bei deinem Hosting undwenn du bei deinem Hoster das hättest,
was ich bezweifle,dass ein Standard Hoster
das mitliefern wird,könntest du das benutzen.
Ich habe das explizit nurauf meiner lokalen Kopie
benutzt, weil jedes ProfilingTool produziert Overhead.
Dementsprechend würde ichdas, sofern es nicht zwingend
notwendig ist, nie auf einProduktivsystem einsetzen.
Wie gesagt, für die lokale Entwicklungbenutzen wir DDEV und bei DDEV kommt das
direkt mit, weswegen ich dort nur dieentsprechende Datei austauschen musste.
Details, wie man das installieren muss,steht auf der Seite.
Ich sehe keine Hände mehr.
Zeit für eine Frage haben wir noch.
Eine Frage haben wir noch.
Keine?
Daniel, du auch keine?
Dann danke ich euch für dieAufmerksamkeit.