Mengoptimalkan Query Sequelize
Pada kesempatan kali ini saya akan berbagi tips cara mengoptimalkan Query Sequelize, mari kita selami kawan..
masalah
Jika anda melihat perlambatan yang nyata di ujung depan, Anda tahu ada sesuatu yang tertinggal di suatu tempat. Jika Anda bekerja dengan aplikasi full-stack, itu bisa berarti di mana saja. Apakah Anda ingin memeriksa komponen React, tindakan dan titik akhir, atau query atau indeks basis data terlebih dahulu? Mungkinkah ini masalah DevOps atau bahkan masalah jaringan pengiriman konten? Apakah container Docker membutuhkan lebih banyak sumber daya?
Ini adalah pertanyaan yang mulai saya tanyakan pada diri sendiri ketika saya menggali lubang kelinci mencoba untuk mengoptimalkan AdBuilder. AdBuilder adalah program desain yang digunakan untuk membuat materi iklan di sini di GumGum. Digunakan oleh tim desain, operasi, dan penjualan sebagai alat otomatis untuk mempercepat pembuatan dan penayangan iklan. Pengguna dapat membuat salah satu unit iklan mereka dengan mengunggah aset, mengubah ukuran dan menyeret aset tersebut, menambahkan animasi, dan terakhir mengekspor markup HTML. Selama bertahun-tahun, ini telah berkembang dari prototipe menjadi aplikasi lengkap juga seiring kami terus menambahkan lebih banyak fitur dab aplikasi telah merasakannya.
Riset
AdBuilder adalah aplikasi full stack dengan front end React dan back end Node.js. Itu juga menggunakan ORM yang disebut Sequelize untuk mengelola interaksi dengan database.
Awalnya, query Sequelize sangat sederhana. Ini karena fungsinya sangat sederhana. Banyak permintaan untuk satu tabel tanpa data bersarang.
Namun, seiring dengan berkembangnya fungsionalitas aplikasi, query menjadi jauh lebih kompleks. Saya perlu menambahkan asosiasi yang menyertai data yang relevan, dan saya berakhir dengan contoh berikut.
Ketika pengujian lokal menjadi berantakan, saya pertama kali mulai menyadari betapa lambatnya aplikasi saya. Setiap kali saya menyegarkan halaman atau mengirim permintaan, butuh terlalu banyak detik untuk memengaruhi waktu pengembangan. Terlebih lagi, di lingkungan produksi, saya mendapatkan laporan pengguna bahwa aplikasi saya tergantung dengan tindakan tertentu yang terkait dengan grup aset, tetapi ketika saya menguji query itu secara lokal, semuanya tampak baik-baik saja. Memeriksa latensi ini hanya dalam produksi membuatnya sulit untuk dilacak karena saya harus mendorong, memicu, dan menguji build setiap kali saya mencoba memperbaikinya.
Setelah beberapa tes tanpa hasil yang tidak biasa, saya memutuskan untuk menyetel jaringan saya. Ini memberi kami ide yang lebih baik tentang penyebab stagnasi terbesar. Seperti disebutkan di atas, kami telah menemukan bahwa TTFB (waktu ke bit pertama) dari beberapa titik akhir sangat tinggi. Beberapa permintaan ini membutuhkan waktu 3 detik hanya untuk menunggu tanggapan, dan Anda dapat mengoptimalkan lebih dari 1 detik. Di sinilah saya mulai mempertanyakan apakah Sequelize bisa menjadi masalah kita.
Setelah menggali lebih dalam, saya menemukan pertanyaan lain yang bermasalah. Mereka semua juga menggunakan parameter include untuk mengambil data dari tabel terkait lainnya.
Jika Anda menggunakan parameter ini, Sequelize menggabungkan query tabel terkait dengan pernyataan bergabung. Ini mudah, tetapi mahal karena data terkait disarangkan dalam satu respons. Bahkan jika Anda menggunakan parameter include untuk menggabungkan query dari tabel yang berbeda dan menyarangkan query lain di dalamnya, ini pada dasarnya membuat satu query yang sangat besar, semuanya dirangkai oleh peningkatan gabungan. Selain itu, jika Anda menambahkan tabel dengan banyak asosiasi ke penyertaan, baris duplikat akan dibuat dan Anda harus menghilangkan duplikat sebelum menguraikan ke dalam model.
Memperbaiki
Untuk mengatasi masalah ini, Sequelize memiliki parameter lain yang disebut terpisah. Sequelize sebenarnya memiliki sedikit atau tidak ada dokumentasi tentang apa yang dilakukan pengaturan. Itu hanya dari menggulir artikel dan masalah serupa, saya perhatikan beberapa penyebutan parameter ambigu ini. Namun, parameter individual ini terbukti sangat penting dalam mengoptimalkan query kompleks yang menyertakan data bersarang terkait.
Ini hanya dapat digunakan dalam asosiasi banyak-ke-banyak, tetapi seperti namanya, ini mengambil query bersarang sebelumnya dan menjalankannya satu per satu atau satu per satu. Sebagai bonus, hasil setiap query kemudian digabungkan dalam memori, sehingga Anda dapat mempertahankan respons yang sama tanpa harus mengubah cara pengaturan data Anda.
Apa artinya ini bagi situasi kami: Kami dapat memisahkan query dan menjalankannya secara terpisah satu sama lain, sangat meningkatkan efisiensi. Mengukur sebelum dan sesudah kinerja beberapa titik akhir, kami mengharapkan peningkatan 10x. Salah satu titik akhir GET berubah dari 2,3 detik menjadi hanya 200 milidetik. Kami juga dapat menargetkan query lain dan mengoptimalkan kinerja di sana menggunakan metode dan asosiasi serupa.
Ini tidak berarti bahwa Sequelize adalah satu-satunya penyebab latensi yang kami alami, atau bahwa itu bukan alat yang cocok untuk digunakan ORM secara umum. Bagian lain dari aplikasi yang digunakan untuk fungsi administratif juga mengalami keterlambatan permintaan yang signifikan. Bagian ini awalnya dibuat menggunakan perpustakaan lain, Epilog dan Finale. Setelah menggantinya langsung dengan Sequelize, kinerjanya meningkat secara signifikan. Selain itu, Sequelize membuatnya lebih mudah untuk memfaktorkan ulang area aplikasi Anda yang belum dipertahankan selama beberapa waktu.
Seperti semua pilihan arsitektur, satu ukuran tidak cocok untuk semua. Buat keputusan berdasarkan kebutuhan Anda dan lihat mana yang paling berhasil. Bersiaplah untuk melihat di balik layar dan terus menemukan.