Thema: performance
-
Continuous Profiling in Produktion: permanent laufende 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 über die gesamte Flotte hinweg am meisten CPU verbraucht hat oder was sich zwischen zwei Versionen geändert hat; Sampling-Profiler machen es günstig genug, um dauerhaft eingeschaltet zu bleiben, und Laufzeit-Endpunkte wie Gos /debug/pprof/ oder eBPF-Agenten liefern die Profile.
-
Systemaufrufe mit strace -c nach Zeit zusammenfassen, Overhead und perf trace als Alternative
strace -c zählt Zeit, Aufrufe und Fehler pro Systemaufruf, statt jeden Aufruf auszugeben. Laut dem strace-Manual läuft ein getraceter Prozess jedoch langsamer als ein nicht getraceter; perf trace, beschrieben als von strace inspiriertes Werkzeug auf Basis von perf_events statt ptrace, ist die unkompliziertere Alternative, wenn dieser Overhead ins Gewicht fällt.
-
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.
-
Erster Blick auf die Solaris-Performance: prstat, vmstat, mpstat, iostat und zpool iostat
prstat -a/-Z, vmstat, mpstat, iostat -xnz und zpool iostat sind fünf rein lesende Befehle, die unter Solaris 11.4 die meisten ersten Performance-Fragen abdecken. Sie bieten Zonen-Unterstützung und Details zur Disk-Latenz, die ähnlich benannte Linux-Tools anders darstellen.
-
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.
-
Windows-Server-Leistungsindikatoren mit Get-Counter abtasten und als CSV exportieren
Get-Counter tastet benannte Indikatorpfade in einem wählbaren Intervall ab, fortlaufend oder für eine feste Anzahl Proben. Export-Counter (nur Windows PowerShell 5.1) behält im nativen BLG-Format alle Felder bei, und relog wandelt einen Mitschnitt nachträglich in CSV um, auch ohne den ursprünglichen Export-Counter-Befehl.
-
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.
-
Performance-Diagnose im macOS-Terminal: top, vm_stat, memory_pressure, fs_usage und powermetrics
macOS bringt Werkzeuge aus BSD-Tradition und Apple-eigene Tools mit, die einen Teil von top/vmstat/iostat/strace unter Linux abdecken, jedoch mit anderen Namen, Einheiten und Rechteanforderungen: top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics und sample <pid>.
-
CPU und I/O pro Prozess mit pidstat und /proc/<pid>/io: die Ursache von I/O-Wait finden
pidstat liefert CPU-, Speicher- und Disk-I/O-Werte pro Task, ohne dass ein Name aus der Ausgabe von top herausgefiltert werden muss. Wer /proc/<pid>/io direkt liest, trennt logisches I/O (rchar/wchar, inklusive Cache) vom physischen read_bytes/write_bytes, das tatsächlich das Gerät erreicht.
-
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.
Maschinenlesbar: JSON