Beim Entwickeln von Software gilt oft der Grundsatz „Arbeitszeit ist teurer als Rechenzeit“. Was bringt es mir, wenn eine nicht performancekritische Anfrage 100ms schneller ausgeführt wird, das Projekt durch den Optimierungsaufwand aber in Verzug kommt?
Das Problem hierbei ist allerdings die Definition von „performancekritisch“. Projekte wachsen, Anwendungsumgebungen werden größer und was Anfangs eine „nicht kritische“ Methode war, bremst jetzt auf einmal die komplette Anwendung. In so einem Fall das Performanceleck zu finden kann schwierig werden – bei PHP können einem allerdings Tools wie XDebug und KCachegrind helfen.
Das Setup ist sehr einfach, einfach php5-xdebug installieren, in der xdebug.ini (oder der php.ini)
xdebug.profiler_enable=1
hinzufügen, ggf. den Webserver neu Starten und schon werden cachegrind Files im /tmp erzeugt.
Zum visualisieren der Dateien kann man jetzt das Tool KCachegrind (oder am Mac z.b. QCachegrind) verwenden – schon sieht man schön übersichtlich, welche Methoden wieviel Zeit einnehmen (absolut oder relativ zur Ausführungszeit) und wo/wie oft diese aufgerufen wurden, usw.
Ausprobieren lohnt sich – gerade wenn man fremde Frameworks verwendet findet man so schnell Performancefallen ohne sich lang durch den Code zu wühlen.
Kritisch: Fehler in Elasticsearch mit JDK22 kann einen sofortigen Stop des Dienstes bewirken
Update Seit gestern Abend steht das Release 8.13.2 mit dem BugFix zur Verfügung. Kritischer Fehler Der Elasticsearch Dienst kann ohne Vorankündigung stoppen. Diese liegt an einem Fehler mit JDK 22. In der Regel setzt man Elasticsearch mit der "Bundled" Version ein....
0 Kommentare