Thema: performance
-
Continuous Profiling in Produktion: dauerhaft aktive Sampling-Profile und was sie beantworten
Continuous Profiling erstellt systematisch über die Zeit CPU- und Speicherprofile und speichert sie als beschriftete Serien, sodass ein Team fragen kann, welche Funktion gestern flottenweit am meisten CPU verbraucht hat oder was sich zwischen zwei Versionen geändert hat; Sampling-Profiler machen das günstig genug, um es dauerhaft laufen zu lassen, und Laufzeit-Endpunkte wie Gos /debug/pprof/ oder eBPF-Agenten liefern die Profile.
-
Eine Änderung benchmarken: Aufwärmphase, Wiederholungen, Streuung und was zu berichten ist
Ein Zeitvergleich ist nur dann ein Ergebnis, wenn er dem Rauschen standhält: die Arbeitslast fixieren, Aufwärmläufe verwerfen, viele Wiederholungen jeder Variante verschachteln, die Statistik vor der Datenbetrachtung festlegen und die Streuung sowie die Umgebung zu jeder Zahl mit angeben. Ein Unterschied, der kleiner ist als die Streuung zwischen Läufen, ist kein Befund.
-
Die USE-Methode zum Aufspüren von Performance-Engpässen
Für jede Ressource (CPU, Speicher, Festplatten, Netzwerk, Sperren) Auslastung, Sättigung und Fehler prüfen; die USE-Methode ist eine Checkliste, die Engpässe schnell findet, ohne zuerst auf der Anwendungsebene zu raten.
-
Antwortkomprimierung: wo sie erfolgen sollte und was auszunehmen ist
Textantworten (HTML, JSON, Markdown) am Proxy oder in der Anwendung komprimieren, bereits komprimierte und gestreamte Inhalte auslassen, ETags über Kodierungen hinweg ehrlich halten und Vary: Accept-Encoding setzen.
-
Wie viel des Kontexts eines Agenten ist in echten Läufen Tool-Ausgabe, und ändert Kürzen den Aufgabenerfolg?
Offene Frage: Die MCP-Spezifikation besagt, dass Clients Tool-Ergebnisse validieren sollten, bevor sie sie an das Modell weitergeben, überlässt die Menge aber dem Client; welcher Anteil der Token ist in protokollierten Agentenläufen Tool-Ausgabe statt Anweisungen oder Überlegung, und ändert das Kürzen, Zusammenfassen oder Filtern von Tool-Ausgaben den Aufgabenerfolg, die Kosten und die Latenz?
-
Responsive Bilder mit srcset, sizes und picture
srcset mit Breitenbeschreibungen zusammen mit einem sizes-Attribut lässt den Browser die kleinste Bilddatei wählen, welche die Fläche beim aktuellen Viewport und der aktuellen Pixeldichte füllt; x-Beschreibungen liefern Bilder fester Grösse in mehreren Dichten; picture mit source-Elementen behandelt Art Direction und Format-Fallback. width und height stets angeben, damit sich das Layout während des Ladens nicht verschiebt.
-
Generieren, kritisieren, überarbeiten: wann sich eine Selbstprüfschleife lohnt
Eine Schleife, in der das Modell seine eigene Ausgabe kritisiert und überarbeitet, verbessert Ergebnisse, wenn die Kritik über ein externes Signal verfügt (Tests, ein Validator, eine Quelle) und über eine feste Bewertungsvorgabe; ohne beides zeigen veröffentlichte Ergebnisse, dass sie Antworten verschlechtern kann, und jede Runde kostet mindestens zwei zusätzliche Aufrufe, deren Eingabe mit dem Entwurf mitwächst.
-
VACUUM, Autovacuum und Tabellen-Bloat
PostgreSQLs MVCC hinterlässt nach Updates und Deletes tote Zeilenversionen; VACUUM gibt diese frei und pflegt Statistiken sowie den Schutz vor Transaktions-ID-Wraparound. Autovacuum sollte aktiviert bleiben und für stark genutzte Tabellen abgestimmt werden.
-
Webfont-Ladeverhalten: font-display, Preload, unicode-range-Subsetting und metrikangepasste Fallbacks
Text beim ersten Rendern anzeigen und die Marken-Schrift ohne Layout-Sprünge laden: Schriftschnitte mit unicode-range aufteilen, damit nur genutzte Schriftsysteme heruntergeladen werden, font-display je nach Rolle wählen (optional für Fliesstext, swap für Überschriften), die für das erste Rendern nötigen Dateien mit crossorigin preloaden und einen Fallback-Schriftschnitt mit size-adjust sowie Ascent/Descent-Overrides deklarieren, damit Zeilen vor und nach dem Wechsel gleich umbrechen.
-
ES-Module-Builds mit deklarierten Nebenwirkungen verkleinern Consumer-Bundles stärker als CommonJS-Builds
Hypothese: Bei einer Bibliothek mit vielen unabhängigen Funktionen erhält ein Consumer, der nur einige davon importiert, ein kleineres Bundle, wenn die Bibliothek als ES-Module mit einer sideEffects-Deklaration ausgeliefert wird, als wenn sie als CommonJS ausgeliefert wird, weil Tree Shaking von der statischen Import/Export-Struktur abhängt; ein auf Fixtures basierender Vergleich wird vorgeschlagen.
-
Wann asyncio hilft und wann nicht
asyncio führt viele E/A-lastige Aufgaben auf einem Thread aus, indem es an await-Punkten pausiert; es beschleunigt CPU-lastigen Code nicht, und blockierende Aufrufe innerhalb von Coroutinen legen die gesamte Event-Loop lahm.
-
Web Vitals: Was LCP, INP und CLS messen
Core Web Vitals sind drei Feldmetriken: Largest Contentful Paint (Renderzeit des grössten sichtbaren Elements, Ziel 2,5 s), Interaction to Next Paint (längste Interaktionslatenz, Ziel 200 ms) und Cumulative Layout Shift (unerwartete Bewegung, Ziel 0,1), jeweils am 75. Perzentil der Seitenaufrufe beurteilt.
-
Wann lohnt sich clientseitiges Routing noch, jetzt, da Browser bfcache, Prerendering und dokumentübergreifende View Transitions bieten?
Offene Frage: In-Page-Router wurden eingeführt, um vollständige Seitenaufrufe zu vermeiden, auf Kosten von Shell-Auslieferung, 404-Behandlung, Scroll- und Fokus-Wiederherstellung und eines Bundles, das zuerst eintreffen muss; der Back/Forward-Cache, die Speculation-Rules-API und dokumentübergreifende View Transitions adressieren die ursprünglichen Beweggründe inzwischen auf Mehrseiten-Websites. Für welche Websites und Interaktionsmuster gewinnt ein In-Page-Router noch messbar?
-
Einen Memory Leak mit tracemalloc-Snapshots finden
Das Tracing früh mit PYTHONTRACEMALLOC oder tracemalloc.start(nframe) starten, nach dem Aufwärmen einen Snapshot nehmen und einen weiteren nach N Iterationen, Import-Rauschen herausfiltern und compare_to(..., 'lineno') nach Zeilen absuchen, deren Grösse proportional zu N wächst; für die Aufrufer auf die Gruppierung 'traceback' wechseln.
-
Zwischen Threads, Prozessen und asyncio für eine Python-Arbeitslast wählen
Zuerst den Hot Path klassifizieren: Warten auf I/O passt zu asyncio (viele Verbindungen, asynchrone Bibliotheken) oder zu einem Thread-Pool (wenige blockierende Aufrufe); reine Python-CPU-Arbeit braucht Prozesse oder einen Free-Threaded-Build; nativer Code, der das GIL freigibt, kann Threads nutzen. Jeden Pool begrenzen, die Prozess-Startmethode explizit wählen und den Abschaltpfad schreiben.
-
Caching in Anwendungen: Ablaufzeiten, Invalidierung und Schutz vor dem Ansturm
Ein Anwendungs-Cache hält abgeleitete Daten und darf jederzeit verloren gehen; korrekt bleibt er nur durch bewusste Invalidierung: Ablaufzeit je Datenklasse, Löschen statt Überschreiben beim Schreiben, Versionskennung im Schlüssel und eine Sperre gegen gleichzeitiges Nachladen heisser Schlüssel.
-
Ein Flame Graph lesen: Breite bedeutet Samples, die x-Achse ist keine Zeit
Ein Flame Graph stapelt aufgezeichnete Call-Stacks so, dass die Breite eines Frames den Anteil der Samples abbildet und die Höhe die Stack-Tiefe; die x-Achse ist alphabetisch sortiert, nicht nach Zeit. Breite Plateaus am oberen Rand als CPU-Hotspots lesen, breite Frames mit vielen schmalen Kindern als Aufrufer, die seltener aufgerufen werden sollten, und daran denken, dass ein CPU-Flame-Graph kein Warten zeigen kann.
-
SVG-Icons: Inline-Markup, ein Sprite mit use, oder ein img-Element
Inline-SVG lässt sich mit currentColor und CSS stylen, wiederholt aber bei jedem Vorkommen dieselben Bytes; ein Sprite vom gleichen Origin, referenziert mit use, wird einmal gecacht und folgt trotzdem der Textfarbe; ein img ist cachebar, aber für CSS undurchsichtig. Je nach Rolle des Icons wählen, dekorative Icons vor assistiven Technologien verbergen, und jedes Icon mit fester Grösse versehen, damit nichts verrutscht, während das Sprite lädt.
-
Datenbank-Connection-Pooling und seine Grenzen
Jede PostgreSQL-Verbindung ist ein Prozess mit Speicherkosten; Anwendungen sollten einen kleinen, an die tatsächliche Nebenläufigkeit angepassten Pool führen, Timeouts für den Verbindungsbezug setzen und Request-Handler nie ad hoc eigene Verbindungen öffnen lassen.
-
Lasttests mit offenen und geschlossenen Workload-Modellen
Bei einem geschlossenen Modell wartet eine feste Anzahl virtueller Benutzer nach jeder Antwort, bevor die nächste Anfrage gesendet wird, sodass ein langsamer werdender Server seine eigene Last drosselt und die schlechtesten Phasen ungemessen bleiben; bei einem offenen Modell treffen Anfragen unabhängig von der Fertigstellung mit einer festen Rate ein. Das Modell aus der gestellten Frage ableiten und bei jeder Zahl angeben.
Maschinenlesbar: JSON