Engineering

Engineering

Bagaimana Mythex dibangun dan dijalankan, termasuk apa yang rusak dan cara kami memperbaikinya.

• Republish yang Gagal Tidak Pernah Menghapus Backend yang Berfungsi — Republish yang gagal bisa menghapus API live aplikasi, atau membiarkan versi rusak tetap berjalan. Tiga perbaikan cara Mythex membatalkan publish yang gagal.
• Alert yang Berbunyi Sekali, Bukan Sekali per Server — Alert harian datang lima kali dalam satu sore. Dedupe di memori gagal dengan dua server dan deploy; state bersama memperbaikinya, dan kegagalan kini mengirim alert.
• Pindah ke Workspace yang Lebih Besar Tanpa Membuat Siapa Pun Menunggu — Seperempat workspace kami tertahan di 1 GB setelah pindah ke 2 GB. Perbaikan pertama membuat satu orang menunggu tujuh menit. Apa yang kami ubah, dan ubah lagi.
• Menagih Database Berdasarkan Apa yang Benar-Benar Dipakai — Dulu kami memperkirakan biaya database tiap aplikasi, dan perkiraannya meleset ke dua arah. Sekarang setiap database ditagih dari pemakaian yang terukur, jam demi jam.
• Menangkap Aplikasi yang Crash Tepat Setelah Dipublikasikan — Tiga publish lolos health check kami padahal API-nya crash beberapa detik setelah setiap boot. Penyebabnya: menghitung crash dalam daftar yang dibatasi lima entri.
• Menjaga Giliran Agen yang Berat Gambar Tetap dalam Memori — Giliran agen yang terus memeriksa pindaian katalog kehabisan memori di 952 MB. Tiga penyebab menahan gambar terlalu lama, dan cara kami memperbaikinya.
• Menjaga Giliran Agen yang Panjang Tetap dalam Context Window — Sub-agen kami bisa membesar hingga model menolaknya, berhenti dini, atau salah menghitung token Rusia. Tiga perbaikan agar pekerjaan AI panjang bisa selesai.
• Menjaga Chat Tetap Hidup Saat Ponsel Tidur — Ponsel tidur dan berpindah tab saat membangun. Dua bug membuat chat macet atau menampilkan separuh balasan. Begini cara kami menemukan dan memperbaikinya.
• Bagaimana Satu Chat Berat Bisa Menjatuhkan API Kami — Pada 28 September kedua server API kehabisan memori bersamaan. Perbaikan sebenarnya: memuat riwayat chat berdasarkan ukuran, bukan jumlah.
• Menekan Publish Dua Kali Kini Hanya Mempublish Sekali — Tiga permintaan publish untuk satu aplikasi berjalan bersamaan dan masing-masing memulai deploy penuh. Begini database kini memutuskan siapa yang mempublish.
• Pelajaran SEO dari Memperbaiki Situs Kami Sendiri — Markup FAQ ganda, thumbnail yang salah di Google, halaman template yang tak diklik, dan jalur yang ditolak edge kami: temuan kami di mythex.ai dan perbaikannya.
• Situs Statis Kini Tetap Online Selama Dipublikasikan Ulang — Dulu, publikasi ulang situs statis mengosongkan situs sebelum unggahan. Kini situs lama tetap melayani sampai yang baru siap, dan perubahan tampil dalam hitungan detik.
• Crash Kehabisan Memori yang Tersembunyi di Label Progres — Agen AI kami kehabisan memori saat menulis satu file besar. Penyebabnya bukan model atau sub-agen paralel, melainkan label status yang dikirim ulang 41.000 kali.
• File Swap yang Hilang dan Membekukan Server Kami — Server produksi berhenti merespons tanpa crash, karena thrashing page cache di mesin tanpa swap, bukan kehabisan memori. Apa yang terjadi dan yang kami ubah.
• Membangunkan Database Tanpa Koneksi Mati — Aplikasi yang bangun dari tidur menahan permintaan pertamanya 10 hingga 12 detik karena koneksi database yang mati. Cara kami menurunkannya menjadi 2,3 detik.
• Kami Membatasi Laju Layanan Kami Sendiri — Batas laju per alamat di API kami memperlakukan layanan sendiri seperti satu pengguna sibuk, sehingga di produksi mereka mendapat 429. Cara kami menemukan dan memperbaikinya.
• Mengapa Kami Memindahkan Server Mythex ke ARM — Setelah pekerjaan berat pindah ke sandbox per proyek, server kami hanya memakai sepertiga memorinya. Instance ARM yang lebih kecil memangkas biaya sekitar 30%. Begini caranya.
• Bagaimana Kami Membuat Deploy Turun ke Nol Error 502 — Watchdog yang berlomba dengan deploy dan load balancer yang terlambat menyadari: cara kami menemukan dan memperbaikinya, dan mengukur deploy dari 10 error 502 menjadi nol.