Berpindah ke Ruang Kerja Lebih Besar Tanpa Menyebabkan Sesiapa Menunggu

Setiap projek Mythex mendapat ruang kerjanya sendiri: sebuah komputer awan kecil tempat ejen menulis kod dan pratonton aplikasi anda berjalan. Kami telah menaikkan memori ruang kerja baharu daripada 1 GB kepada 2 GB, tetapi ruang kerja lama kekal pada 1 GB. Pada hari kami menyemaknya, kira-kira suku daripadanya masih kecil. Pembetulan pertama kami memindahkan projek ke ruang kerja yang lebih besar apabila ia dibuka seterusnya. Pada hari pertama ia dilancarkan dalam pengeluaran, pembetulan itu menyebabkan seorang pengguna menunggu tujuh minit. Kami meletakkan had masa yang tegas padanya, kemudian mengeluarkan pemindahan itu daripada proses membuka projek sepenuhnya.

Mengapa ruang kerja lama kekal kecil

Penyedia sandbox kami menetapkan saiz ruang kerja semasa ia dicipta, dan mengekalkannya melalui setiap jeda dan sambungan semula. Menukar templat, iaitu resipi yang digunakan untuk membina ruang kerja baharu, hanya memberi kesan kepada ruang kerja yang dicipta selepas perubahan itu. Tiada apa yang mengubah saiz ruang kerja yang sudah sedia ada.

Ini penting. Salah satu ruang kerja yang kecil kehabisan memori semasa git push ketika pratonannya sedang dimulakan, dan tidak bertindak balas selama 11 minit. Satu publish gagal kerananya.

Percubaan pertama: pindahkan projek apabila ia bangkit

Ruang kerja dijeda apabila tiada siapa menggunakannya dan bangkit apabila projek dibuka. Ketika bangkit kelihatan sebagai saat yang betul untuk memindahkan projek, kerana belum ada sesiapa yang bekerja di dalamnya.

Pemindahan itu berfungsi seperti berikut:

Semak saiznya. Jika ruang kerja lebih kecil daripada 2 GB, pindahkannya. Jika saiznya tidak diketahui, jangan buat apa-apa.
Jangan ganggu publish. Publish membaca fail ruang kerja, jadi jika satu sedang berjalan, langkau pemindahan.
Pakej projek. Arkibkan semua yang ada dalam projek, termasuk sejarah git-nya, iaitu setiap checkpoint yang dimiliki projek itu, dan fail .env aplikasi, yang menjadi milik pemiliknya. Tetapi tinggalkan kebergantungan yang dipasang (node_modules), yang boleh dipasang semula.
Salin terus. Strim arkib dari ruang kerja lama ke ruang kerja 2 GB yang baharu, supaya ia tidak perlu muat dalam memori pelayan kami sendiri.
Bandingkan sebelum bertukar. Kira fail, baca checkpoint terkini, dan kira checkpoint, dalam kedua-dua ruang kerja. Tukar hanya jika ketiga-tiganya sepadan.
Simpan yang lama jika apa-apa gagal. Sebarang ralat, atau sebarang ketidakpadanan, akan membuang ruang kerja baharu dan membuka projek dalam yang lama, seperti biasa.

Satu perincian dalam perbandingan itu lebih penting daripada yang kelihatan. Semakan itu berjalan sebagai akaun pentadbir, dan git enggan membaca repositori yang dimiliki oleh pengguna lain. Ia tidak mencetak apa-apa di kedua-dua belah, dan “tiada apa-apa” sepadan dengan “tiada apa-apa”, jadi semakan itu lulus tanpa membandingkan sejarah langsung. Kami memberitahu git untuk mempercayai direktori itu, dan menambah ujian supaya perkara itu tidak berulang.

Apa yang salah pada hari pertama

Pada hari pertama dalam pengeluaran, semasa mengarkibkan satu projek, had masa arahan lima minit tercapai di dalam proses bangkit. Pemilik menunggu tujuh minit untuk ruang kerjanya dibuka. Dan kerana pemindahan itu gagal, projek masih kecil, jadi pembukaan seterusnya akan mencuba lagi dan membuat mereka menunggu sekali lagi.

Pemindahan yang membuatkan seseorang menunggu ketika membuka projek mereka sendiri ialah pertukaran yang buruk. Tujuan melakukannya ketika bangkit ialah supaya tiada siapa perasan.

Percubaan kedua: bajet yang tegas

Pada hari yang sama, kami menukar empat perkara:

Satu minit untuk keseluruhan pemindahan. Setiap langkah, iaitu menyemak saiz, memampatkan, mencipta ruang kerja baharu, menyalin, mengekstrak dan membandingkan, berkongsi satu bajet 60 saat. Apabila ia habis, projek dibuka dalam ruang kerja lama.
Hentikan kerja, bukan sekadar menunggu. Berhenti menunggu di pihak kami tidak mencukupi jika pengarkiban masih berjalan di dalam ruang kerja yang bakal digunakan pemilik. Setiap arahan arkib kini dihentikan di dalam ruang kerja itu sendiri, sebentar sebelum bajet tamat. Jika ruang kerja baharu tiba selepas kami menyerah, ia dibuang.
Jangan buat pemilik menunggu pembersihan. Memadam arkib sementara kini berlaku di latar belakang.
Jangan cuba lagi pada setiap pembukaan. Projek yang gagal dipindahkan dibiarkan selama 24 jam, supaya kegagalan hanya menyebabkan paling banyak satu kelewatan sehari, bukan satu setiap kali dibuka.

Percubaan ketiga: keluarkan daripada proses bangkit

Ini menjadikan kes paling buruk satu minit. Tetapi satu minit tetap satu minit, dan kami sedar pemindahan itu tidak perlu berada di laluan sesiapa pun.

Tiada ruang kerja dicipta pada 1 GB lagi. Jadi ia bukan proses berterusan; ia adalah kerja sekali dengan senarai tetap ruang kerja. Membuatnya di dalam proses bangkit bermakna seorang pengguna sebenar membayar untuk setiap pemindahan yang perlahan, dan satu-satunya cara kami tahu bahawa sesebuah ruang kerja tidak boleh dipindahkan ialah apabila seseorang baru sahaja menunggunya.

Jadi kami mengeluarkan pemindahan itu daripada proses bangkit sepenuhnya. Membuka projek kini berfungsi seperti sebelumnya. Ruang kerja kecil yang tinggal dikendalikan sebagai satu kumpulan yang diselia: tiada siapa sedang menunggu, dan ruang kerja yang tidak boleh dipindahkan akan muncul dalam laporan kumpulan itu, di mana kami boleh melihatnya, dan bukannya di hadapan pemiliknya.

Apa yang kami pelajari daripadanya

Menukar saiz tidak selalunya mungkin. Apabila platform menetapkan saiz semasa penciptaan, menaikkan lalai hanya membantu perkara yang baharu. Rancang untuk yang lama.
“Tiada siapa menggunakannya lagi” tetap bermakna ada seseorang sedang menunggu. Kerja yang dilakukan semasa memasuki produk ialah kerja yang diperhatikan oleh seseorang.
Letakkan bajet pada apa sahaja yang berada di laluan pengguna, dan hentikan kerja apabila bajet habis. Tamat masa di pihak kami sementara arahan terus berjalan di tempat lain hanya memindahkan masalah.
Migrasi sekali sepatutnya berada dalam kerja sekali. Menyembunyikannya di dalam tindakan harian menjadikannya lebih murah untuk ditulis tetapi lebih mahal untuk dijalankan.
Uji pemeriksaan keselamatan anda. Perbandingan yang tidak membandingkan apa-apa kelihatan sama seperti perbandingan yang lulus.

Jika anda membina di atas Mythex, tiada apa yang perlu anda buat: matlamatnya ringkas, iaitu lebih sedikit ruang kerja kehabisan memori, dengan pembukaan projek yang sepantas sebelumnya. Cara ruang kerja dijeda dan dibangkitkan diliputi dalam dokumentasi di bawah ruang kerja peribadi. Untuk kisah kehabisan memori yang lain, lihat ranap kehabisan memori yang tersembunyi dalam label kemajuan.