Daftar periksa performa dan skalabilitas untuk Azure Queue Storage
Microsoft telah mengembangkan banyak praktik yang terbukti untuk mengembangkan aplikasi berkinerja tinggi dengan Queue Storage. Daftar periksa ini mengidentifikasi kunci praktik yang dapat diikuti pengembang untuk mengoptimalkan performa. Ingatlah praktik ini saat Anda merancang aplikasi dan sepanjang proses.
Azure Storage memiliki skalabilitas dan target performa untuk kapasitas, kecepatan transaksi, dan bandwidth. Untuk informasi lebih lanjut tentang target skalabilitas Azure Storage, lihat Skalabilitas dan target performa untuk akun penyimpanan standar dan Skalabilitas dan target performa untuk Queue Storage.
Daftar periksa
Artikel ini mengatur praktik yang terbukti untuk performa ke dalam daftar periksa yang dapat Anda ikuti saat mengembangkan aplikasi Queue Storage Anda.
Target skalabilitas
Jika aplikasi Anda mendekati atau melebihi salah satu target skalabilitas, aplikasi mungkin mengalami peningkatan latensi atau pembatasan transaksi. Saat Azure Storage membatasi aplikasi Anda, layanan mulai mengembalikan kode galat 503 (Server Busy) atau 500 (Operation Timeout). Menghindari kesalahan ini dengan tetap berada dalam batas target skalabilitas adalah bagian penting untuk meningkatkan performa aplikasi Anda.
Untuk informasi lebih lanjut tentang target skalabilitas untuk Queue Storage, lihat Skalabilitas dan target kinerja Azure Storage.
Jumlah akun penyimpanan maksimum
Jika Anda mendekati jumlah maksimum akun penyimpanan yang diizinkan untuk kombinasi langganan/wilayah tertentu, apakah Anda menggunakan beberapa akun penyimpanan untuk memecahkan supaya meningkatkan masuk, keluar, operasi I/O per detik (IOPS), atau kapasitas? Dalam skenario ini, Microsoft menyarankan agar Anda memanfaatkan peningkatan batas untuk akun penyimpanan untuk mengurangi jumlah akun penyimpanan yang diperlukan untuk beban kerja Anda jika memungkinkan. Hubungi Dukungan Azure untuk meminta peningkatan batas untuk akun penyimpanan Anda.
Kapasitas dan target transaksi
Jika aplikasi Anda mendekati target skalabilitas untuk satu akun penyimpanan, pertimbangkan untuk mengadopsi salah satu pendekatan berikut:
- Jika target skalabilitas untuk antrean tidak mencukupi untuk aplikasi Anda, gunakan beberapa antrean dan distribusikan pesan ke antreannya.
- Pertimbangkan kembali beban kerja yang menyebabkan aplikasi Anda mendekati atau melebihi target skalabilitas. Dapatkah Anda mendesainnya secara berbeda untuk menggunakan lebih sedikit bandwidth atau kapasitas, atau lebih sedikit transaksi?
- Jika aplikasi Anda harus melebihi salah satu target skalabilitas, maka buat beberapa akun penyimpanan dan partisi data aplikasi Anda di beberapa akun penyimpanan tersebut. Jika Anda menggunakan pola ini, pastikan untuk mendesain aplikasi Anda sehingga Anda dapat menambahkan lebih banyak akun penyimpanan di masa depan untuk penyeimbangan muatan. Akun penyimpanan tidak memiliki biaya selain penggunaan Anda dalam hal data yang disimpan, transaksi yang dilakukan, atau data yang ditransfer.
- Jika aplikasi Anda mendekati target bandwidth, pertimbangkan untuk memadatkan data di pihak klien untuk mengurangi bandwidth yang diperlukan untuk mengirim data ke Azure Storage. Meskipun mengompresi data dapat menghemat bandwidth dan meningkatkan performa jaringan, data juga dapat berdampak negatif pada performa. Evaluasi dampak performa dari persyaratan pemrosesan tambahan untuk pemadatan dan dekompresi data di pihak klien. Perlu diingat bahwa menyimpan data terkompresi dapat membuat pemecahan masalah lebih sulit karena mungkin lebih menantang untuk melihat data menggunakan alat standar.
- Jika aplikasi Anda mendekati target skalabilitas, pastikan Anda menggunakan backoff eksponensial untuk percobaan ulang. Sebaiknya hindari mencapai target skalabilitas dengan menerapkan rekomendasi yang dijelaskan dalam artikel ini. Namun, menggunakan backoff eksponensial untuk percobaan ulang mencegah aplikasi Anda mencoba kembali dengan cepat, yang dapat membuat pembatasan lebih buruk. Untuk informasi lebih lanjut, lihat bagian Kesalahan Waktu Habis dan Server Sibuk.
Jaringan
Batasan jaringan fisik aplikasi mungkin berdampak signifikan pada performa. Bagian berikut ini menjelaskan beberapa batasan yang mungkin ditemui pengguna.
Kemampuan jaringan klien
Bandwidth dan kualitas tautan jaringan berperan penting dalam performa aplikasi, seperti yang dijelaskan di bagian berikut.
Throughput
Untuk bandwidth, masalahnya sering kali pada kemampuan klien. Instans Azure yang lebih besar memiliki NIC dengan kapasitas yang lebih besar, jadi Anda harus mempertimbangkan menggunakan instans yang lebih besar atau lebih banyak VM jika Anda memerlukan batas jaringan yang lebih tinggi dari satu komputer. Jika Anda mengakses Azure Storage dari aplikasi lokal, aturan yang sama berlaku: pahami kemampuan jaringan perangkat klien dan konektivitas jaringan ke lokasi Azure Storage dan tingkatkan sesuai kebutuhan atau desain aplikasi Anda agar berfungsi dalam kemampuannya.
Kualitas tautan
Seperti halnya penggunaan jaringan apa pun, perlu diingat bahwa kondisi jaringan yang mengakibatkan kesalahan dan kehilangan paket memperlambat throughput yang efektif. Menggunakan Wireshark atau Monitor Jaringan mungkin membantu dalam mendiagnosis masalah ini.
Lokasi
Dalam lingkungan terdistribusi apa pun, menempatkan klien di dekat server memberikan performa terbaik. Untuk mengakses Azure Storage dengan latensi terendah, lokasi terbaik untuk klien Anda berada dalam wilayah Azure yang sama. Misalnya, jika Anda memiliki aplikasi web Azure yang menggunakan Azure Storage, temukan keduanya dalam satu wilayah, seperti AS Barat atau Asia Tenggara. Sumber daya yang berada di lokasi yang sama mengurangi latensi dan biaya, karena penggunaan bandwidth dalam satu wilayah gratis.
Jika aplikasi klien mengakses Azure Storage tetapi tidak dihosting dalam Azure, seperti aplikasi perangkat seluler atau layanan perusahaan lokal, maka menemukan akun penyimpanan di wilayah yang dekat dengan klien tersebut dapat mengurangi latensi. Jika klien Anda tersebar luas (misalnya, beberapa di Amerika Utara, dan beberapa di Eropa), pertimbangkan untuk menggunakan satu akun penyimpanan per wilayah. Pendekatan ini lebih mudah diterapkan jika data yang disimpan aplikasi khusus untuk pengguna individual, dan tidak memerlukan replikasi data antar akun penyimpanan.
SAS dan CORS
Misalkan Anda perlu memberikan otorisasi kode seperti JavaScript yang berjalan di browser web pengguna atau di aplikasi ponsel untuk mengakses data di Azure Storage. Salah satu pendekatannya adalah dengan membangun aplikasi layanan yang bertindak sebagai proksi. Perangkat pengguna mengautentikasi dengan layanan, yang pada gilirannya memberikan otorisasi akses ke sumber daya Azure Storage. Dengan cara ini, Anda dapat menghindari mengekspos kunci akun penyimpanan Anda di perangkat yang tidak aman. Namun, pendekatan ini menempatkan overhead yang signifikan pada aplikasi layanan, karena semua data yang ditransfer antara perangkat pengguna dan Azure Storage harus melewati aplikasi layanan.
Anda dapat menghindari penggunaan aplikasi layanan sebagai proksi untuk Azure Storage dengan menggunakan tanda tangan akses bersama (SAS). Dengan menggunakan SAS, Anda dapat mengaktifkan perangkat pengguna untuk membuat permintaan langsung ke Azure Storage dengan menggunakan token akses terbatas. Misalnya, jika pengguna ingin mengunggah foto ke aplikasi Anda, maka aplikasi layanan Anda dapat menghasilkan SAS dan mengirimkannya ke perangkat pengguna. Token SAS dapat memberikan izin untuk menulis ke sumber daya Azure Storage untuk interval waktu tertentu, setelah itu token SAS kedaluwarsa. Untuk informasi selengkapnya tentang SAS, lihat Memberikan akses terbatas ke sumber daya Azure Storage dengan menggunakan tanda tangan akses bersama (SAS).
Biasanya, browser web tidak akan mengizinkan JavaScript di halaman yang dihosting oleh situs web di satu domain untuk melakukan operasi tertentu, seperti operasi tulis, ke domain lain. Dikenal sebagai kebijakan asal yang sama, kebijakan ini mencegah skrip berbahaya di satu halaman untuk mendapatkan akses ke data di halaman web lain. Namun, kebijakan asal yang sama dapat menjadi batasan saat membangun solusi di cloud. Berbagi sumber daya lintas asal (CORS) adalah fitur browser yang memungkinkan domain target untuk berkomunikasi dengan browser yang mempercayai permintaan berasal dari domain sumber.
Misalnya, aplikasi web yang berjalan di Azure membuat permintaan sumber daya ke akun Azure Storage. Aplikasi web adalah domain sumber, dan akun penyimpanan adalah domain target. Anda dapat mengonfigurasi CORS untuk salah satu layanan Azure Storage untuk berkomunikasi dengan browser web yang permintaan dari domain sumber dipercaya oleh Azure Storage. Untuk informasi lebih lanjut tentang CORS, lihat Dukungan berbagi sumber daya lintas asal (CORS) untuk Azure Storage.
SAS dan CORS dapat membantu Anda menghindari beban yang tidak perlu pada aplikasi web Anda.
Konfigurasi .NET
Untuk proyek yang menggunakan .NET Framework, bagian ini mencantumkan beberapa pengaturan konfigurasi cepat yang dapat Anda gunakan untuk melakukan peningkatan performa yang signifikan. Jika Anda menggunakan bahasa selain .NET, periksa untuk melihat apakah konsep serupa berlaku dalam bahasa yang Anda pilih.
Meningkatkan batas koneksi default
Catatan
Bagian ini berlaku untuk proyek yang menggunakan .NET Framework, karena pengumpulan koneksi dikontrol oleh kelas ServicePointManager. .NET Core memperkenalkan perubahan signifikan sekeliling manajemen kumpulan koneksi, di mana pengumpulan koneksi terjadi pada tingkat HttpClient dan ukuran kumpulan tidak dibatasi secara default. Ini berarti bahwa koneksi HTTP secara otomatis diskalakan untuk memenuhi beban kerja Anda. Menggunakan versi terbaru .NET disarankan, jika memungkinkan, untuk memanfaatkan peningkatan performa.
Untuk proyek yang menggunakan .NET Framework, Anda dapat menggunakan kode berikut untuk meningkatkan batas koneksi default (yang biasanya 2 di lingkungan klien atau 10 di lingkungan server) menjadi 100. Biasanya, Anda harus mengatur nilainya kira-kira sejumlah alur yang digunakan oleh aplikasi Anda. Atur batas koneksi sebelum membuka koneksi apa pun.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Untuk mempelajari selengkapnya tentang batas kumpulan koneksi di .NET Framework, lihat .NET Framework Koneksi ion Pool Limits dan Azure SDK baru untuk .NET.
Untuk bahasa pemrogram lainnya, lihat dokumentasi untuk menentukan cara mengatur batas koneksi.
Meningkatkan jumlah alur minimum
Jika Anda menggunakan panggilan sinkron bersama dengan tugas asinkron, Anda mungkin ingin meningkatkan jumlah utas di kumpulan utas:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Untuk informasi selengkapnya, lihat metode ThreadPool.SetMinThreads.
Paralelisme tidak terbatas
Meskipun paralelisme bisa sangat bagus untuk performa, berhati-hatilah menggunakan paralelisme yang tidak terbatas, yang berarti bahwa tidak ada batasan yang diberlakukan pada jumlah utas atau permintaan paralel. Pastikan untuk membatasi permintaan paralel untuk mengunggah atau mengunduh data, untuk mengakses beberapa partisi di akun penyimpanan yang sama, atau untuk mengakses beberapa item di partisi yang sama. Jika paralelisme tidak dibatasi, aplikasi Anda dapat melebihi kemampuan perangkat klien atau target skalabilitas akun penyimpanan, yang mengakibatkan keterlambatan dan pembatasan yang lebih lama.
Pustaka dan alat klien
Untuk performa terbaik, selalu gunakan pustaka dan alat klien terbaru yang disediakan oleh Microsoft. Pustaka klien Azure Storage tersedia untuk berbagai bahasa. Azure Storage juga mendukung PowerShell dan Azure CLI. Microsoft secara aktif mengembangkan pustaka dan alat klien ini dengan mempertimbangkan performa, menjaganya tetap mutakhir dengan versi layanan terbaru, dan memastikan bahwa mereka menangani banyak praktik performa yang terbukti secara internal. Untuk informasi lebih lanjut, lihat dokumentasi referensi Azure Storage.
Handel kesalahan layanan
Azure Storage mengembalikan kesalahan saat layanan tidak dapat memproses permintaan. Memahami kesalahan yang mungkin dikembalikan oleh Azure Storage dalam skenario tertentu sangat membantu untuk mengoptimalkan performa.
Kesalahan Waktu Habis dan Server Sibuk
Azure Storage mungkin membatasi aplikasi Anda jika mendekati batas skalabilitas. Dalam beberapa kasus, Azure Storage mungkin tidak dapat menangani permintaan karena beberapa kondisi sementara. Dalam kedua kasus, layanan mungkin mengembalikan kesalahan 503 (Server Busy) atau 500 (Timeout). Kesalahan ini juga dapat terjadi jika layanan menyeimbangkan ulang partisi data untuk memungkinkan throughput yang lebih tinggi. Aplikasi klien biasanya harus mencoba kembali operasi yang menyebabkan salah satu kesalahan ini. Namun, jika Azure Storage membatasi aplikasi Anda karena melebihi target skalabilitas, atau bahkan jika layanan tidak dapat melayani permintaan karena beberapa alasan lain, percobaan ulang yang agresif mungkin memperburuk masalah. Disarankan menggunakan kebijakan percobaan kembali back off eksponensial, dan pustaka klien default untuk perilaku ini. Misalnya, aplikasi Anda mungkin mencoba kembali setelah 2 detik, lalu 4 detik, lalu 10 detik, lalu 30 detik, lalu menyerah sepenuhnya. Dengan cara ini, aplikasi Anda secara signifikan mengurangi bebannya pada layanan, daripada memperburuk perilaku yang dapat menyebabkan pembatasan.
Koneksi kesalahan dapat segera dicoba kembali, karena bukan hasil pembatasan dan diharapkan bersifat sementara.
Kesalahan yang tidak dapat dicoba kembali
Pustaka klien menangani percobaan ulang dengan kesadaran tentang kesalahan mana yang dapat dicoba kembali dan yang tidak dapat. Namun, jika Anda memanggil Azure Storage REST API secara langsung, ada beberapa kesalahan yang tidak boleh Anda coba lagi. Misalnya, kesalahan 400 (Bad Request) menunjukkan bahwa aplikasi klien mengirim permintaan yang tidak dapat diproses karena tidak dalam bentuk yang diharapkan. Mengirim ulang permintaan ini menghasilkan respons yang sama setiap kali, sehingga tidak ada gunanya mencobanya kembali. Jika Anda memanggil Azure Storage REST API secara langsung, ketahui potensi kesalahan dan apakah kesalahan tersebut harus dicoba kembali.
Untuk informasi selengkapnya tentang kode galat Azure Storage, lihat Status dan kode galat.
Nonaktifkan algoritma Nagle
Algoritma Nagle secara luas diterapkan di seluruh jaringan TCP/IP sebagai sarana untuk meningkatkan performa jaringan. Namun, ini tidak optimal dalam semua keadaan (seperti lingkungan yang sangat interaktif). Algoritma Nagle berdampak negatif pada performa permintaan ke Azure Table Storage, dan Anda harus menonaktifkannya jika memungkinkan.
Ukuran pesan
Performa antrean dan skalabilitas menurun seiring meningkatnya ukuran pesan. Hanya letakkan informasi yang dibutuhkan penerima dalam pesan.
Pengambilan batch
Anda dapat mengambil hingga 32 pesan dari antrean dalam satu operasi. Pengambilan batch dapat mengurangi jumlah perjalanan pulang-pergi dari aplikasi klien, yang sangat berguna untuk lingkungan, seperti perangkat seluler, dengan latensi tinggi.
Interval polling antrean
Sebagian besar aplikasi mengumpulkan pesan dari antrean, yang dapat menjadi salah satu sumber transaksi terbesar untuk aplikasi tersebut. Pilih interval polling Anda dengan bijak: polling terlalu sering dapat menyebabkan aplikasi Anda mendekati target skalabilitas untuk antrean. Namun, pada 200.000 transaksi seharga $0,01 (pada saat penulisan), polling prosesor tunggal sekali setiap detik selama sebulan akan dikenakan biaya kurang dari 15 sen sehingga biaya biasanya bukan faktor yang memengaruhi pilihan interval polling Anda.
Untuk informasi biaya terbaru, lihat Harga Azure Storage.
Lakukan operasi perbarui pesan
Anda dapat melakukan operasi perbarui pesan untuk meningkatkan batas waktu tak terlihat atau memperbarui informasi status pesan. Pendekatan ini dapat menjadi lebih efisien daripada memiliki alur kerja yang meneruskan pekerjaan dari satu antrean ke yang berikutnya, karena setiap langkah pekerjaan selesai. Aplikasi Anda dapat menyimpan status pekerjaan ke pesan dan kemudian melanjutkan pekerjaan, alih-alih mengantre ulang pesan untuk langkah pekerjaan berikutnya setiap kali sebuah langkah selesai. Perlu diingat bahwa setiap operasi perbarui pesan diperhitungkan dalam target skalabilitas.
Arsitektur aplikasi
Gunakan antrean untuk membuat arsitektur aplikasi Anda dapat diskalakan. Berikut ini daftar beberapa cara Anda dapat menggunakan antrean untuk membuat aplikasi Anda lebih dapat diskalakan:
- Anda dapat menggunakan antrean untuk membuat backlog pekerjaan untuk diproses dan memuluskan beban kerja di aplikasi Anda. Misalnya, Anda dapat mengantrekan permintaan dari pengguna untuk melakukan pekerjaan intensif prosesor seperti mengubah ukuran gambar yang diunggah.
- Anda dapat menggunakan antrean untuk memisahkan bagian dari aplikasi sehingga Anda dapat menskalakannya secara mandiri. Misalnya, ujung depan web dapat menempatkan hasil survei dari pengguna ke dalam antrean untuk analisis dan penyimpanan nanti. Anda dapat menambahkan lebih banyak instans peran pekerja untuk memproses data antrean sesuai kebutuhan.