Bagaimana Kami Meningkatkan Performa Moove Sebesar 59%
Sebagian besar pengguna Moove jauh dari server kami. Begini cara kami memangkas waktu respons pertama 59% tanpa memindahkan server, dan mengapa itu sulit.Jarak adalah dependensi kami yang paling lambat
Sebagian besar orang yang membuka aplikasi Moove menggunakan jaringan seluler di Nigeria dan Indonesia, ribuan kilometer dari server yang melayani mereka. Bulan ini kami mengubah cara permintaan mereka sampai ke kami, dan waktu hingga byte pertama (TTFB), yaitu waktu antara ponsel mengirim permintaan dan potongan pertama jawaban tiba, turun 59%, dari 0.74 detik menjadi 0.31 detik. Kami tidak memindahkan satu server pun untuk mencapainya.
Tulisan ini menjelaskan mengapa jarak ternyata lebih merugikan daripada dugaan kami, apa yang kami ubah, bagian yang ternyata lebih sulit daripada perubahannya sendiri, dan apa yang akan kami sampaikan kepada tim lain yang hendak melakukan hal yang sama.
Mengapa satu perjalanan panjang menjadi tiga
Para insinyur menyebut jeda antara pengiriman sesuatu dan kedatangannya sebagai latensi, dan waktu yang dibutuhkan sebuah pesan untuk mencapai server lalu balasannya kembali sebagai waktu pulang-pergi (RTT). Dari Lagos ke server kami, RTT berkisar antara 200 hingga 300 milidetik. Angka itu sendiri masih bisa diterima. Masalahnya, sebuah permintaan jarang bepergian sendirian.
Sebelum ponsel dapat meminta apa pun melalui koneksi aman, ia harus menyelesaikan dua handshake, yaitu pertukaran singkat yang menyiapkan sebuah koneksi. Handshake TCP membuka koneksi, lalu handshake TLS menyepakati kunci enkripsi yang menjaganya tetap privat. Masing-masing memakan satu perjalanan pulang-pergi penuh. Baru setelah itu permintaan itu sendiri dikirim, yang merupakan perjalanan ketiga. Pada 250 milidetik per perjalanan, pengguna menunggu sekitar tiga perempat detik sebelum server kami mengerjakan apa pun.
Di jaringan seluler, biaya itu dibayar jauh lebih sering daripada yang Anda harapkan. Ponsel berpindah antar menara seluler, radio masuk mode tidur untuk menghemat baterai, dan aplikasi dikirim ke latar belakang. Setiap peristiwa itu dapat memutus koneksi, dan permintaan berikutnya harus dimulai dari koneksi dingin, yaitu koneksi yang belum melewati handshake apa pun, dan membayar lagi seluruh biaya penyiapan. Koneksi hangat, yang sudah terbuka dan aman, langsung melompat ke permintaan.
Kami tidak bisa memindahkan Lagos lebih dekat ke server kami. Namun kami bisa memindahkan proses penyiapannya lebih dekat ke Lagos.
Memindahkan handshake, bukan server
Jaringan pengiriman konten (CDN) biasanya digambarkan sebagai cache: kumpulan lokasi di seluruh dunia yang menyimpan salinan berkas agar dapat dilayani dari dekat. Kami memakainya untuk alasan lain. Untuk API kami, yaitu antarmuka yang dipakai aplikasi untuk semua yang dikerjakannya, caching dimatikan sepenuhnya. Setiap permintaan tetap menempuh perjalanan ke origin kami, sebutan CDN untuk server di belakangnya.
Yang berubah adalah di mana koneksi dimulai. Kini ponsel membuka koneksinya ke lokasi edge terdekat, juga disebut titik kehadiran (PoP): salah satu situs CDN di seluruh dunia, yang sering kali berjarak puluhan milidetik, bukan ratusan. Edge melakukan terminasi TLS, artinya koneksi aman dari ponsel berakhir di sana. Edge lalu memakai ulang kumpulan koneksi hangat ke origin kami, yang dijaga tetap terbuka dengan keep-alive, yaitu pengaturan yang membiarkan koneksi tetap terbuka di antara permintaan alih-alih menutupnya. Dua perjalanan penyiapan yang mahal terjadi pada lompatan pendek, dan hanya permintaan itu sendiri yang menyeberangi samudra, melalui koneksi yang sudah hangat.
Tiga perjalanan panjang menjadi satu perjalanan panjang dan dua perjalanan pendek. Itulah seluruh idenya.
Sisanya sengaja kami buat sebiasa mungkin:
- Klien tidak merasakan apa pun. Aplikasi dan situs web tetap memakai alamat yang sama, sehingga tidak perlu rilis aplikasi dan tidak ada yang harus memperbarui apa pun.
- Perilaku saat gagal tetap sama. Batas waktu (timeout) sama dengan sebelumnya, jadi apa pun yang dulu gagal akan gagal dengan cara yang sama. Kami tidak menginginkan jenis galat baru.
- Edge menutup koneksi yang menganggur lebih dulu. Setiap koneksi memiliki idle timeout, yaitu berapa lama koneksi boleh dibiarkan tidak terpakai sebelum ditutup. Jika server kami menutup koneksi yang sepi sementara edge masih mengira koneksi itu terbuka, permintaan berikutnya akan gagal. Dengan menetapkan timeout edge lebih pendek, edge selalu menyerah lebih dulu dan membuka koneksi baru.
- Protokol yang lebih baru untuk ponsel. Ponsel dapat terhubung lewat HTTP/3, versi terbaru dari protokol permintaan web. Protokol ini berjalan di atas QUIC, yang melebur kedua handshake menjadi satu perjalanan pulang-pergi dan lebih tahan terhadap kehilangan paket yang umum di jaringan seluler.
- Tidak ada wilayah yang tertinggal. Paket jaringan edge yang lebih murah sering melewatkan lokasi di bagian dunia tempat pengguna kami berada, jadi kami memilih cakupan penuh.
Apa yang kami ukur
Kami mengukur dari Sydney, yang jaraknya ke server kami kira-kira sama jauh dengan Lagos, dengan membandingkan jalur lama dan jalur baru. Untuk masing-masing, kami membuka lima koneksi dingin baru, kasus yang paling penting di jaringan seluler, lalu mengambil median, juga ditulis p50: hasil tengah, yang dikalahkan separuh permintaan dan tidak dikalahkan separuh lainnya. Proyek yang sama juga mengaktifkan kompresi untuk skrip situs web kami, yang sebelumnya dikirim dalam ukuran penuh. Kompresi memperkecil berkas sebelum dikirim dan peramban mengembangkannya kembali saat tiba; kami memakai Brotli, format kompresi yang dibuat untuk web.
| Yang kami ukur | Sebelum | Sesudah | Peningkatan |
|---|---|---|---|
| Handshake TCP dan TLS selesai (p50) | 490 ms | 59 ms | 88% lebih cepat |
| Waktu hingga byte pertama (p50) | 743 ms | 307 ms | 59% lebih cepat |
| Ukuran muatan skrip beranda | 1.76 MB | 560 KB | 68% lebih kecil |
Waktu hingga byte pertama adalah sumber angka 59% itu. Koneksi yang dulu butuh setengah detik untuk disiapkan kini siap dalam kurang dari sepersepuluh detik, dan kunjungan pertama ke situs web kami kini mengunduh sepertiga dari sebelumnya, pada koneksi yang membuat banyak orang membayar setiap megabyte.
Angka-angka ini berasal dari satu kota, bukan tolok ukur global. Meski begitu, hitungannya berlaku juga untuk Lagos dan Jakarta, dan di sanalah pengguna kami berada.
Bagian tersulit adalah mengetahui siapa yang memanggil
Menaruh sesuatu di depan server Anda itu mudah. Menjaga perlindungan Anda tetap bekerja di belakangnya adalah tempat sebagian besar usaha kami tercurah.
Seperti kebanyakan platform pembayaran, Moove menggunakan pembatasan laju (rate limiting), yaitu batas jumlah permintaan yang boleh dibuat satu pemanggil dalam waktu tertentu, dan batas itu dikunci pada alamat IP pemanggil, angka yang mengidentifikasi sebuah perangkat di internet. Di balik jaringan edge, setiap permintaan tiba dari alamat lokasi edge, bukan alamat pengguna. Jika tidak ada hal lain yang berubah, semua orang di Lagos akan berbagi satu jatah, dan satu sore yang ramai akan mulai menolak orang yang tidak bersalah.
Solusinya bertumpu pada dua gagasan.
Percayai tepat lapisan yang Anda miliki. CDN adalah sejenis reverse proxy, yaitu server yang berada di depan server Anda dan meneruskan permintaan. Setiap proxy menambahkan alamat asal permintaan yang diterimanya ke sebuah header standar bernama X-Forwarded-For, sehingga pemanggil sebenarnya berada sejumlah langkah tetap, atau hop, di belakang dalam daftar itu. Salah menentukan angka itu adalah bug ke dua arah. Jika menghitung terlalu sedikit lapisan, setiap pengguna tampak seperti lokasi edge-nya. Jika terlalu banyak, Anda mulai memercayai entri yang ditulis sendiri oleh pemanggil. Karena itu kami menjadikan angka tersebut properti infrastruktur, bukan kode. Angka itu berubah pada saat yang sama dengan jaringannya, dan layanan kami menolak untuk dijalankan jika nilainya tidak masuk akal, alih-alih menebak.
Biarkan edge menjamin pemanggil, dan percayai hanya edge. Edge kini menulis alamat pemanggil sebenarnya pada setiap permintaan dan menimpa apa pun yang dikirim pemanggil di tempat itu. Perlindungan kami hanya memercayai nilai tersebut bila dapat memverifikasi bahwa permintaan benar-benar melewati edge kami. Setiap batas yang dulu dikunci pada alamat jaringan kini dikunci pada pemanggil sebenarnya untuk lalu lintas edge. Kami menambahkan aturan ini di samping yang lama, bukan mengubahnya, sehingga setiap perubahan dalam peluncuran hanyalah penambahan murni yang bisa ditinjau siapa pun dalam sekali baca.
Bug yang kami tangkap sebelum rilis
Moove Profiles dapat berada di domain milik pedagang sendiri. Permintaan untuk domain tersebut diteruskan melalui situs web kami dengan domain pedagang disertakan, agar situs tahu profil mana yang harus ditampilkan.
Edge baru di depan situs web membuang informasi semacam itu dari permintaan masuk, dan itu memang benar, karena pengunjung tidak boleh bisa menetapkannya. Namun itu juga berarti begitu situs web dipindahkan ke belakang edge, setiap domain pedagang diam-diam akan menampilkan beranda Moove, bukan profil pedagang tersebut.
Kami menangkapnya dalam peninjauan, memindahkan jalur domain pedagang ke rute tersendiri terlebih dahulu, dan membuat infrastruktur kami menolak menerapkan perubahan situs web di mana pun pemindahan itu belum dilakukan. Kesalahan yang dulu hanya ada di kepala peninjau kini menjadi sesuatu yang dihentikan oleh proses build.
Pelajaran umumnya: saat Anda menambahkan lapisan yang membersihkan masukan, cari semua hal yang bergantung pada masukan yang akan Anda bersihkan.
Bagaimana kami meluncurkannya
Infrastruktur pembayaran tidak boleh sekadar "deploy lalu lihat", jadi kami mengubah staging lebih dulu dan produksi sesudahnya, dan beberapa pilihan menjaga peralihan tetap tenang. Kami menurunkan TTL (time to live) pada rekaman DNS kami, direktori internet yang mengubah nama seperti moove.xyz menjadi alamat server. TTL adalah berapa lama seluruh internet boleh menyimpan jawaban itu, dan kami memangkasnya dari satu jam menjadi lima menit, satu jam penuh sebelum ada yang dipindahkan, sehingga jawaban lama sudah kedaluwarsa di mana-mana dan pengembalian ke kondisi semula akan berlaku dalam hitungan menit. Kami menjaga rekaman alamat dalam bentuk yang dapat diganti di tempat, karena menghapus dan membuatnya kembali akan meninggalkan celah, dan celah adalah gangguan layanan. Setiap langkah berisiko menjadi perubahan kecil tersendiri, dengan langkah untuk membatalkannya ditulis secara berurutan.
Apa yang akan kami sampaikan kepada tim lain
Jika pengguna Anda jauh dari server Anda, jaringan edge layak dimiliki bahkan ketika tidak men-cache apa pun. Sebelum beralih:
- Daftarkan semua yang membaca alamat pemanggil, termasuk batas laju, daftar izin, sinyal penipuan, log audit, dan aturan keamanan. Masing-masing akan melihat alamat edge kecuali Anda mengubahnya.
- Jadikan jumlah lapisan tepercaya bagian dari infrastruktur Anda, dan tolak untuk dijalankan ketika nilainya salah.
- Biarkan edge mencatat pemanggil sebenarnya, dan percayai catatan itu hanya pada lalu lintas yang dapat Anda verifikasi berasal dari edge Anda.
- Pastikan server Anda hanya menerima lalu lintas melalui edge, dan amati dulu sebelum Anda menegakkannya.
- Jika Anda men-cache halaman, bangun kunci cache, yaitu kumpulan detail permintaan yang dipakai cache untuk memutuskan apakah dua permintaan dapat berbagi satu respons tersimpan, dari semua hal yang memang membuat respons berbeda. Server mencantumkan detail tersebut dalam header Vary, jadi bacalah header itu dan jangan mengandalkan ingatan.
- Ukur sebelum dan sesudah, dan lihat waktu handshake serta waktu hingga byte pertama secara terpisah, agar Anda dapat membedakan penyiapan koneksi dari waktu yang dihabiskan server Anda untuk bekerja.
Ke depan
Sebagian besar halaman kami dipersonalisasi, sehingga cache edge situs web sebagian besar masih menganggur untuk saat ini. Peningkatan koneksi berlaku untuk setiap halaman, dan halaman tertentu kini dapat memilih untuk di-cache bila aman dibagikan. Meng-cache respons API memerlukan desain dan peninjauan tersendiri, dan itulah hal berikutnya yang ingin kami teliti.
Uang seharusnya bergerak secepat jaringan, bukan secepat cahaya menyeberangi samudra.
Jika Anda membangun di atas Moove, baca pengantar kami tentang API dan SDK pembayaran Web3 dan Moove Developer Program.
Ditulis oleh tim engineering moove.xyz.
Tentang moove.xyz
moove.xyz adalah platform fintech Web3 global yang dibangun untuk pergerakan nilai yang tanpa izin dan tanpa hambatan. Kami memberdayakan bisnis dan konsumen di mana pun untuk mengirim, menerima, melakukan staking, dan menukar kripto apa pun di blockchain apa pun — semua dalam satu platform.
Kami adalah salah satu perusahaan fintech Web3 pertama di dunia yang berinovasi dan membangun infrastruktur pembayaran kripto dan keuangan terdesentralisasi full-stack, memungkinkan cakupan terintegrasi dan komprehensif di seluruh akses dompet multi-chain, handle dompet yang dipersonalisasi, pertukaran token lintas chain, transaksi lintas chain yang tertanam, dan jaringan keuangan sosial terdesentralisasi. Produk-produk utama kami mencakup Moove Profile, Moove Send, Moove Receive, Moove Stake, Moove Swap, Moove Rewards, Moove Discover, dan lainnya.
Misi kami sederhana — menciptakan dan mendistribusikan teknologi keuangan yang tanpa izin dan tanpa hambatan untuk 1 miliar pengguna Web3 berikutnya. Kami percaya sepenuhnya bahwa masa depan pergerakan uang dan nilai akan bebas biaya, tanpa batas, tanpa izin, tanpa hambatan, dan dibangun untuk semua orang — dan kami sedang membangun platform fintech Web3 terbaik untuk mewujudkan masa depan itu.
Uangmu. Gerakanmu.






